Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

MNET 2.0: Difference between revisions

From MoodleDocs
Line 98: Line 98:


=== New Networking Test Client ===
=== New Networking Test Client ===
Previously there was a hidden MNET test client that could only be accessed via url directly by administrators.  This has been cleaned up, rewritten to work with the method signature and placed under the Development Menu in the main Administration Block.  This can be used to perform introspection on remote hosts and find out what methods are available and what their method signatures are.  It is very helpful for debugging MNET.
This was done as part of MDL-21261


=== Removal of 'auto create users' configuration option ===
=== Removal of 'auto create users' configuration option ===
Under the configuration screen for the MNET authentication plugin, there was previously a setting called 'auto add remote users'.  As far as I can understand, there was never a case where this should have been off, so it has been removed now.
See the following forum post:  http://moodle.org/mod/forum/discuss.php?d=141491 and the bug: MDL-21327
=== Reworked MNET administration screens ===
Most of admin/mnet has been updated to use Moodle Forms and the new Output API.  This should not result in functional changes, but there may be some smaller aesthetic ones.  Not all screens have been rewritten yet.
The relevant bug is MDL-21256

Revision as of 23:26, 16 February 2010

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:

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.

See the following bugs about this:

Other code changes

Administrative changes

New Networking Test Client

Previously there was a hidden MNET test client that could only be accessed via url directly by administrators. This has been cleaned up, rewritten to work with the method signature and placed under the Development Menu in the main Administration Block. This can be used to perform introspection on remote hosts and find out what methods are available and what their method signatures are. It is very helpful for debugging MNET.

This was done as part of MDL-21261

Removal of 'auto create users' configuration option

Under the configuration screen for the MNET authentication plugin, there was previously a setting called 'auto add remote users'. As far as I can understand, there was never a case where this should have been off, so it has been removed now.

See the following forum post: http://moodle.org/mod/forum/discuss.php?d=141491 and the bug: MDL-21327

Reworked MNET administration screens

Most of admin/mnet has been updated to use Moodle Forms and the new Output API. This should not result in functional changes, but there may be some smaller aesthetic ones. Not all screens have been rewritten yet.

The relevant bug is MDL-21256