brian moseley wrote: > On Wed, 9 Jan 2002, Mark Maunder wrote: > > > The difference is that AppCluster allows you to call > > multiple remote methods on the server (or on multiple > > distributed servers) simultaneously. However, I wasn't > > aware of PlRPC and I really like the interface i.e. the > > way it creates a copy of the remote object locally and > > allows you to call methods on it as if it were just > > another object. > > would it require too much surgery and api change if you > added the concurrency support to PlRPC?
Well, I guess two methods could be added to the client object. One to add a concurrent request to be called (register_request()) and one to send all registered requests concurrently. I'm not the author though, so you'll have to chat to Jochen about that. The server and transport would have to be rewritten pretty much from scratch I think. The transport needs to be HTTP POST requests and responses. The server needs to be set up as a mod_perl handler that takes advantage of everything mod_perl has to offer. >From my point of view, it's easier to duplicate Jochen's work in AppCluster by adding the same type of interface i.e. creating a copy of a remote object locally and calling methods on that object as per normal while the actual method call is submitted via a POST to a remote mod_perl app server. I dont really mind whether we incorporate this stuff into PlClient or AppCluster or both, but I do think that both the concurrency in AppCluster and tied object API in PlRPC are really useful and would be even better with the remote app server being mod_perl. An idea might be to incorporate both the AppCluster concurrency and PlRPC style api into an Apache::* module that gives us the best of both worlds with mod_perl performance (etc.) on the server side. (and then get rid of AppCluster since it will be redundant) Let me know if that sounds like a good idea and I'll start work on it. Perhaps we could call it Apache::PlRPC (now with added concurrency!) ~mark
