On Wed, 9 Jan 2002, Mark Maunder wrote: > 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.
couldn't you just subclass RPC::PlClient? > 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. why "needs"? i'm sure lots of people would rather run a very lightweight non-http/apache-based 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. seems like the ideal api gives you the best functionality from both original apis and abstracts away the choice of transport and server. > 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) perhaps i misunderstand, but you're suggesting making the client an Apache module? why? i like the idea of being able to write client code that uses the same rpc api no matter whether i choose to use soap, xml-rpc, a more specific http post, plrpc's transport (whatever that might be), or whatever as the transport. not all of the "drivers" would have to support the same feature set (i think your mechanism supports arbitrarily deep data structures?). that rpc api is one of the things p5ee is looking for, i believe.
