brian moseley wrote: > 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 transport is different (HTTP/POST) and I dont think I can easily just drop in another (alternative) transport - I may as well rewrite. > > 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. > Agreed. Are there any more besides a standalone pure perl daemon and mod_perl/apache? > > > 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. > yeah - agreed. > > > 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? Well, the server component (at present) is a mod_perl handler, and I wanted to bundle both together so I stuck in in the Apache namespace (pending any objections of course). Seems like RPC might make more sense if it becomes platform/server neutral, since Apache::* binds the server platform to mod_perl. > 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. It seems like you're asking a bit much here (the holy grail of RPC?). SOAP and xml-rpc are their own client/server system. Are we going to integrate this with both of them and support standalone perl daemons etc.? I considered writing a soap client that allows for concurrent requests, but I found SOAP::Lite to be slow under mod_perl so opted for rolling my own instead. Also SOAP is platform neutral and I'm not sure, but I think it wont allow for perl data structures as complex as Storable does. I think you should probably distinguish between transport and encoding. Transports could be http, https or a plain old socket (if we're talking to a perl daemon) and an encrypted socket connection using CBC. Encodings we've chatted about are Storable's freeze/thaw and SOAP's XML, and then xml-rpc (which I assume has it's own encoding of method name and params etc in xml - although I dont know it at all). I think having various transports is fine. But I'm not sure what the motivation is for varying the encodings, unless we want our client to talk to SOAP and xml-rpc servers, or vice versa. Perhaps integrating PlRPC and AppCluster's client API's and allowing for either standalone daemon or mod_perl server is a good start? We can use HTTP, HTTPS, direct sockets and encrypted sockets as the first transports. The client can have two modes - concurrent remote procedure calls, or creating a copy of the remote object PlRPC style. ~mark.
