Hi all Mnetwork concerned fellows
I was wondering of pro and cons, about designing XML-RPC services and using a mnet client->send() or having a curl call to a jump + wantsurl.
I'm working on an upgraded file_manager version, adding an "capturing URL in the text" filter. As I'm full networked, the filter will send the captured link information to the filemanager instance of the owner's regular mnethost (the host he his know he is from... using a special patch of Mnet that allows that -> Nigel is aware !! ).
Adding the link can be done by triggering a direct URL in the blocks/file_manager implementation, bringing the adequate parameters.
Two implementation solutions :
1. Designing a new XML-RPC service and function call attached to blocks/file_manager. Thus called through a mnet client standard invocation.
2. Having a curl direct call to a local jump url targetting the same foreing URL on remote moodle, and giving required params in the wanturl encoded string.
The question is about quite "philosophic" arguments for and against each one, as both are resulting in side injection of the URL record (what I want), letting the local flow ending as usual.
thanks for arguments... I did'nt found so many !!
XML-RPC is nicer implementation, but needs configuration of services and additional settings in network peer setup (opening services)
curl is straight rough remote call, just using SSO for translating user's identity, produces output (unusable by the curl call) so ugly, but depending on no configuration except standard SSO one.
so ?
Cheers.
Moodle XML-RPC services vs. jump.php + wantsurl
Number of replies: 5Re: Moodle XML-RPC services vs. jump.php + wantsurl
XML-RPC is the nicer way, definitely. You can get your data back in a structured form, without having to worry about the structure of the page on the other end changing. If you can make a service that provides the information you want, I would do it that way. Especially because you already have a trust relationship between both sides.
Re: Moodle XML-RPC services vs. jump.php + wantsurl
I agree with Nigel. For computer-to-computer communication, it is better, philosophicaly, to use XML-RPC. It will give a response that is easier for the computer to parse, which would be important if something goes wrong with the remote call and you need to debug.
However, you should note that Moodle by default doesn't allow MNet calls to blocks. It only searches for XML-RPC calls in the auth/, enrol/, and mod/ directories (plus portfolio/ and repository/ in Moodle 2.0). (See mnet/xmlrpc/server.php, function mnet_server_dispatch for more information on how it maps XML-RPC methods to PHP calls, as I don't think it's documented anywhere.) There are various ways around it, but there may be issues.
Adding a new XML-RPC call for Moodle may be a bit tricky, so from a practical standpoint, it may be easier to use jump.php. (Just remember that you need to send along a few cookies, so that Moodle knows what user you're using.) However, from a philosophical standpoint, it is better to use XML-RPC.
However, you should note that Moodle by default doesn't allow MNet calls to blocks. It only searches for XML-RPC calls in the auth/, enrol/, and mod/ directories (plus portfolio/ and repository/ in Moodle 2.0). (See mnet/xmlrpc/server.php, function mnet_server_dispatch for more information on how it maps XML-RPC methods to PHP calls, as I don't think it's documented anywhere.) There are various ways around it, but there may be issues.
Adding a new XML-RPC call for Moodle may be a bit tricky, so from a practical standpoint, it may be easier to use jump.php. (Just remember that you need to send along a few cookies, so that Moodle knows what user you're using.) However, from a philosophical standpoint, it is better to use XML-RPC.
Re: Moodle XML-RPC services vs. jump.php + wantsurl
Thank you all fellows for your thoughts.
I will follow that path as I already did with many other features in Pairformance.
I agree with you all that XML-RPC is the cleanest way to implement internal server to server data exchange.
Totally agree with Hubert about linking XML-RPC services to a block. This is a request to be done in tracker, as there is absolutely no reason we might have not side-apps bound to an access block that use XML-RPC moodle service implementation to communicate. I exploded already many time the full mnet implementation and maybe do I know it quite as much as Nigel !!
I will tell you about a patch to add this rpclib support in block context.
Cheers : let's go to work !!
I will follow that path as I already did with many other features in Pairformance.
I agree with you all that XML-RPC is the cleanest way to implement internal server to server data exchange.
Totally agree with Hubert about linking XML-RPC services to a block. This is a request to be done in tracker, as there is absolutely no reason we might have not side-apps bound to an access block that use XML-RPC moodle service implementation to communicate. I exploded already many time the full mnet implementation and maybe do I know it quite as much as Nigel !!
I will tell you about a patch to add this rpclib support in block context.
Cheers : let's go to work !!
Re: Moodle XML-RPC services vs. jump.php + wantsurl
If we can attach XML-RPC calls to a block, then that would be great. I'm currently using a dummy auth plugin, because I want to avoid changing too much core code.
Re: Moodle XML-RPC services vs. jump.php + wantsurl
Code to add to /mnet/xmlrpc/server.php
in mnet_server_dispatch :
As an additional routing case §478
in /admin/mnet/adminlib.php : two insert points.
in mnet_get_functions()
in upgrade_RPC_functions()
as last case (at the end)
Note that none of the two latter are really usefull if you do not envisage to publish external RPC enabled functions to trusted XML-RPC hosts. I didn't even test those two adds, as first works. RPC parent attribute must be set to "blocks" and the RPC path should say : "blocks/blockname/rpclib.php/function_name"
Cheers.
in mnet_server_dispatch :
////////////////////////////////////// STRICT BLOCKS/*
} elseif ($callstack[0] == 'blocks') {
list($base, $block, $filename, $functionname) = $callstack;
$includefile = '/blocks/'.$block.'/rpclib.php';
$response = mnet_server_invoke_method($includefile, $functionname, $method, $payload);
$response = mnet_server_prepare_response($response);
echo $response;
}
As an additional routing case §478
in /admin/mnet/adminlib.php : two insert points.
in mnet_get_functions()
// PATCH handle RPC calls in blocks
} elseif ('blocks' == $type) {
$docname = 'rpclib.php';
$relname = '/blocks/'.$parentname.'/'.$docname;
$filename = $CFG->dirroot.$relname;
if (file_exists($filename)) include_once $filename;
$mnet_publishes = $parentname.'_mnet_publishes';
if (function_exists($mnet_publishes)) {
(array)$publishes = $mnet_publishes();
}
// \PATCH handle RPC calls in blocksas second $type test casein upgrade_RPC_functions()
// PATCH handle RPC in blocks
$basedir = $CFG->dirroot.'/blocks';
if (file_exists($basedir) && filetype($basedir) == 'dir') {
$dirhandle = opendir($basedir);
while (false !== ($dir = readdir($dirhandle))) {
$firstchar = substr($dir, 0, 1);
if ($firstchar == '.' or $dir == 'CVS' or $dir == '_vti_cnf') {
continue;
}
if (filetype($basedir .'/'. $dir) != 'dir') {
continue;
}
mnet_get_functions('blocks', $dir);
}
}// \PATCH handle RPC in blocks
as last case (at the end)
Note that none of the two latter are really usefull if you do not envisage to publish external RPC enabled functions to trusted XML-RPC hosts. I didn't even test those two adds, as first works. RPC parent attribute must be set to "blocks" and the RPC path should say : "blocks/blockname/rpclib.php/function_name"
Cheers.