MNET 2.0

Introduction

This page attempts to summarise the changes in MNET between Moodle 1.9 and Moodle 2.0, both from an administrative perspective, and a code perspective.

There are still things to do before 2.0 is released, so this page is a work in progress.

Backwards Compatibility Breaks

Plugins registering MNET services

It used to be that the plugins that needed to export mnet services used a mnet_publishes() method on the class (static or not). This led to a list of hard coded plugins that supported it, and in some cases auth factory involvement, just to get a list of the RPC functions available.

This has now changed to a file containing an array, in db/mnet.php, similar to lib/db/services.php. This file looks something like this (example from the Mahara portfolio plugin):

$publishes = array(

   'pf' => array(
       'apiversion' => 1,
       'classname'  => 'portfolio_plugin_mahara',
       'filename'   => 'lib.php',
       'methods'    => array(
           'fetch_file'
       ),
   ),

); $subscribes = array(

   'pf' => array(
       'send_content_intent' => 'portfolio/mahara/lib.php/send_content_intent',
       'send_content_ready'  => 'portfolio/mahara/lib.php/send_content_ready',
   ),

);

Note that there is a unsymmetricality between the methods that are published and the methods that are subscribed to. This is new .

This also resulted in two new tables. The old tables, mnet_rpc and mnet_service2rpc relate to the methods that are being published. The new tables, mnet_remote_rpc and mnet_remote_service2rpc relate to the methods that are being subscribed to.

See the following bugs about this:

• MDL-21261
• MDL-16269
• MDL-16277

Method signatures

The method signature code used to use a string tokeniser to parse the php files that contained mnet services and store information about them in the database. This was unreliable and slow. We've switched to using php5's reflection utilities, which gives us some information about the code, and the Zend_Server Reflection to get the rest. This uses the native php5 reflection, as well as parsing the phpdoc blocks to find information about the types of function arguments, and the return values.

Because of this, we can now reliably include both argument types and return value information in the method signature, where previously only arguments had been included (and in the case of no arguments, the return value had previously been erroneously used).

This means that before where the method signature looked like this:

array(

   array(
       'type' => 'string',
       'description' => 'something here',
   ),
   array(
       /* ... */
   ),
   /* ... */

)

it now looks like this:

array(

   'parameters' =>  array(
       array(
           'name' => 'token',
           'type' => 'string',
           'description' => 'something here',
       ),
       array(
           /* ... */
       ),
       /* ... */,
   ),
   'return' => array(
       'type' => 'string',
       'description' => 'something here',
   ),

)

Which, although it is unarguably more informative and clearer, is a backwards compatibility break. This information is what is sent as the response to the system/methodSignature xmlrpc method. The only place this is used within Moodle, however, is in the old testclient.php, which was present in code, but not linked to from anywhere. This has been changed and is covered under Administrative changes.

Other code changes

Administrative changes