Hey, All:
I'm working on an mnet-enabled module and am wondering how to tell a moodle mnet client instance to refresh its list of available methods for an mnet server ("peer") that it is registered with.
Can I slowly add methods on the server side and register them as I go (some equivalent to hitting /admin/index.php on the client side), or do I have to stub them in before registering?
Actually, a quick look at the db now makes me doubt that /admin/index.php is registering the new methods on the server side either. Can anyone provide guidance, please?
Thanks,
Brian
Refreshing the list of available methods on client and server?
by Brian Jorgensen -
Number of replies: 8
In reply to Brian Jorgensen
Re: Refreshing the list of available methods on client and server?
by Brian Jorgensen -
Hrm... not sure I understand the model completely yet.
I added the method to the *_mnet_publishes method in my module on the "server" side and hit admin/index.php and my client could then see the method with testclient.php, but I was still getting a permission problem on the client side when I tried to call this new method until I added the method on the client and hit admin/index.php (also a moodle instance for now).
Making the server and client identical feels like a bit of a hack to me, and I wonder if I may have solved the problem in an unintentional way.
How do non-moodle clients like Mahara deal with this? Do they also have to "register" methods locally that they want to call on remote mnet servers?
Thanks,
Brian
I added the method to the *_mnet_publishes method in my module on the "server" side and hit admin/index.php and my client could then see the method with testclient.php, but I was still getting a permission problem on the client side when I tried to call this new method until I added the method on the client and hit admin/index.php (also a moodle instance for now).
Making the server and client identical feels like a bit of a hack to me, and I wonder if I may have solved the problem in an unintentional way.
How do non-moodle clients like Mahara deal with this? Do they also have to "register" methods locally that they want to call on remote mnet servers?
Thanks,
Brian
In reply to Brian Jorgensen
Re: Refreshing the list of available methods on client and server?
by Peter Bulmer -
Hi Brian,
looking at mnet/xmlrpc/client.php, (line 144 in cvshead), I see:
// At this point, we don't care if the remote host implements the
// method we're trying to call. We just want to know that:
// 1. The method belongs to some service, as far as OUR host knows
I don't yet know why mnet wants the method to be defined on our host before being willing to execute it on the remote host.
After a bit of a trawl through mnetland, I can't see anywhere that listServices or listMethods is called to populate local records of what services/methods are available on remote hosts.
Anyone - please feel free to correct me with a reference to a relevant function
Brian - what does your module do?
looking at mnet/xmlrpc/client.php, (line 144 in cvshead), I see:
// At this point, we don't care if the remote host implements the
// method we're trying to call. We just want to know that:
// 1. The method belongs to some service, as far as OUR host knows
I don't yet know why mnet wants the method to be defined on our host before being willing to execute it on the remote host.
After a bit of a trawl through mnetland, I can't see anywhere that listServices or listMethods is called to populate local records of what services/methods are available on remote hosts.
Anyone - please feel free to correct me with a reference to a relevant function
Brian - what does your module do?
In reply to Peter Bulmer
Re: Refreshing the list of available methods on client and server?
by Martín Langhoff -
I don't yet know why mnet wants the method to be defined on our host before being willing to execute it on the remote host.
That's a Donal'ism I suspect. I agree with you, we do not need to know a thing about it locally, mnet is not always symmetric (wrt to the code installed at each end).
In reply to Martín Langhoff
Re: Refreshing the list of available methods on client and server?
by Peter Bulmer -
On re-reading my comment, I realize that I wasn't very clear. Fortunately you seem to have interpreted what I meant, not what I said . For the benefit of anyone else who might read this:
What I meant was "I don't know why mnet insists that the code for the method must exist on the local host before being willing to define the method".
What I meant was "I don't know why mnet insists that the code for the method must exist on the local host before being willing to define the method".
In reply to Peter Bulmer
Re: Refreshing the list of available methods on client and server?
by Peter Bulmer -
Unfortunately, it isn't as easy as just relaxing a check, we also need to define means for one mnet peer to tell each another about what services and methods it offers.
Then (IMO) a db change or three is warranted:
Currently:
app --< host --< host2service >-- service --< service2rpc >-- rpc
At present, there is a defined number of services, defined list of rpc's (methods), and a defined relationship between them.
In host2service every peer is related to every defined service (3 peers w/ 3 services = 9 rows), with the additional information as to whether we subscribe to that service on the remote host, or publish that service to the remote host.
If we allow other mnet peers to tell us what application they are, and services/methods information (and version of that application/service/method), if we don't have that application (version), that service (version), or that method (version) we would then create them.
All this would mean recording version information about applications, services and methods, which application services relate to, and changing the host2service table into service_subscribe and service_publish tables.
Needless to say, I have no pot of money to be able to do this (AFAIK), but I think it's worthwhile discussing 'how it oughta be'. Once that's done, people have something they can point at when they're trying to sell it.
Then (IMO) a db change or three is warranted:
Currently:
app --< host --< host2service >-- service --< service2rpc >-- rpc
At present, there is a defined number of services, defined list of rpc's (methods), and a defined relationship between them.
In host2service every peer is related to every defined service (3 peers w/ 3 services = 9 rows), with the additional information as to whether we subscribe to that service on the remote host, or publish that service to the remote host.
If we allow other mnet peers to tell us what application they are, and services/methods information (and version of that application/service/method), if we don't have that application (version), that service (version), or that method (version) we would then create them.
All this would mean recording version information about applications, services and methods, which application services relate to, and changing the host2service table into service_subscribe and service_publish tables.
Needless to say, I have no pot of money to be able to do this (AFAIK), but I think it's worthwhile discussing 'how it oughta be'. Once that's done, people have something they can point at when they're trying to sell it.
In reply to Peter Bulmer
Re: Refreshing the list of available methods on client and server?
by Peter Bulmer -
The weakness I see in the above approach is that if $MNETPEER1 tells you that it provides MAHARASSO service v2 (but is actually using a poorly developed customisation) when another peer tells you that it provides MAHARASSO v2, you won't enquire what that means, since you think you already know about it.
The most practical way I can see around this atm, is to keep service information for each host. The implication of this is that even if you have 2 standard maharas connecting, each providing the service MAHARASSO v2, because they're different hosts they'll be listed as 2 different services, with 2 different sets of methods.
The most practical way I can see around this atm, is to keep service information for each host. The implication of this is that even if you have 2 standard maharas connecting, each providing the service MAHARASSO v2, because they're different hosts they'll be listed as 2 different services, with 2 different sets of methods.
In reply to Peter Bulmer
Re: Refreshing the list of available methods on client and server?
by Nigel McNie -
I was just going to reply to your last post saying it needed to be per host, then I saw this ;). +1 on this idea.
In reply to Peter Bulmer
Re: Refreshing the list of available methods on client and server?
by Brian Jorgensen -
Hey, Peter:
Thanks for tracking this down; I'm new to Moodle adn php and have been climbing many different technical hills and hadn't seen that yet.
I'm working on an Alfresco integration that will receive zip files of content and put them in the appropriate Moodle course site filesystem; the reasons I chose a module were because I wanted to avoid the "dangerous" database setting and I didn't want to hack auth or enrol so a module is the only alternative.
It's not clear to me if there are multiple types of modules, though, or if they are all activity modules. Anyone?
Brian
Thanks for tracking this down; I'm new to Moodle adn php and have been climbing many different technical hills and hadn't seen that yet.
I'm working on an Alfresco integration that will receive zip files of content and put them in the appropriate Moodle course site filesystem; the reasons I chose a module were because I wanted to avoid the "dangerous" database setting and I didn't want to hack auth or enrol so a module is the only alternative.
It's not clear to me if there are multiple types of modules, though, or if they are all activity modules. Anyone?
Brian