This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: Gunther Birznieks <gunther@extropia.com> From: Mark Maunder <mark@swiftcamel.com> Subject: Re: [ANNOUNCE] Apache::AppCluster 0.2 Date: Wed, 09 Jan 2002 16:58:46 +0000 Gunther Birznieks wrote: > Is this a lot different from PlRPC? > > Perhaps this should be a transport layer that is added to PlRPC rather than > creating a brand-new service? > > Ideally it would be nice if it were architected with mod_perl and HTTP > being the default mechanism of transport but that if you wanted to, you > could make it into a standalone Perl daemon that forked by itself. 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. I could not do this with AppCluster without sacrificing the concurrency it offers. At present you create a single appcluster object and then register the method calls you would like it to call, one by one. You then call a single method (with a timeout) that calls all registered remote methods simultaneously. (It uses non-blocking IO and so provides concurrency in a single thread of execution) re: allowing the server to be a standalone daemon that forks by itself. This project actually started exactly like that. I grabbed the pre-forking server example from the Cookbook and used that as the basis for the server. I found that performance was horrible though, because forking additional servers took too long and I also was using DBI and I missed Apache::DBI (and all the other great apache::* mods) too much. So I used a good solid server that offers a great Perl persistence engine. I'm not sure why anyone would want to roll their own server in Perl. If there is a reason, then I could change the server class to create a server abstraction layer of some kind. ~mark. === To: <modperl@apache.org> From: brian moseley <bcm@maz.org> Subject: Re: [ANNOUNCE] Apache::AppCluster 0.2 Date: Wed, 9 Jan 2002 10:27:38 -0800 (PST) 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? === To: brian moseley <bcm@maz.org> From: Mark Maunder <mark@swiftcamel.com> Subject: Re: [ANNOUNCE] Apache::AppCluster 0.2 Date: Wed, 09 Jan 2002 19:05:35 +0000 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!) === To: <modperl@apache.org> From: brian moseley <bcm@maz.org> Subject: Re: [ANNOUNCE] Apache::AppCluster 0.2 Date: Wed, 9 Jan 2002 11:35:01 -0800 (PST) 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. === To: brian moseley <bcm@maz.org> From: Mark Maunder <mark@swiftcamel.com> Subject: Re: [ANNOUNCE] Apache::AppCluster 0.2 Date: Thu, 10 Jan 2002 01:13:25 +0000 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. ===