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.
