Calling this "cross-language remoting" is kind of a misnomer, because standards like SOAP/XML-RPC are what allow RPC to occur cross-language. Yours is a Perl server solution (by definition), and not based on any RPC standard I recognize, which means developers must use your client APIs. It therefore misses a great deal of the purpose of systems like SOAP/XML-RPC: any-language server, any-language client.
With mod_perlservice, you can host RPC webservices AND webpages all on one
server! Wow.
That's pretty ignorant of mod_* generally. I can host RPC services and pages now all under one Apache, and under one mod_perl, using code with established user bases. So actually, to serve dynamic pages under the same Apache as one hosting mod_perlservice, we'd need to load a second embedded interpreter via mod_perl, whereas we use one to do the same now. So your point is ... backwards.
You have written a mod that embeds the Perl interpreter (as does mod_perl), embeds the Apache API (as does mod_perl), but has as its only application writing RPC interfaces with your proprietary protocol, rather than the much broader/robust feature set offered by mod_perl. It's really about the equivalent to embedding the Perl interpreter into a compiled binary to parse some proprietary file format, rather than publish Perl modules to accomplish the same (or use an existing standard file format to begin with).
Also mod_perlservice's configuration system allows you to host MANY RPC
applications on a single Apache server. Try hosting 25 different remote
apps using XML-RPC; there is no native functionality that enables XML-RPC
to accomplish such feats.
There's a limit to the number of apps you can host with XML-RPC? How do you figure?
Furthermore, mod_perlservice offers a clean programming interface, much cleaner, less complicated, more scalable, and better organized than any system out there. Just try it.
Your article claims similar benefits of ease, but doesn't explain what these benefits are. In the case of Flash '04, it has native support for both SOAP and XML-RPC (a benefit), making the default choices compatible with large collections of ready-to-use web services (another benefit). Writing a SOAP service with SOAP::Lite, for example, can be just as terse as your examples (a benefit), and be instantly compatible with the existing SOAP clients (benefit). Say, ActionScript's out-of-the-box support:
NetServices.setDefaultGatewayUrl("http://hostname.com/gateway";);
gateway = NetServices.createGatewayConnection();
service = gateway.getService("http://www.xmethods.net/sd/2001/ BabelFishService.wsdl", this);
service.BabelFish({translationmode:language, sourcedata:text});
function BabelFish_Result (result) {
translated = result;
}
What benefits does mod_perlservice offer over what we have today?
Well, why not just use mod_perl?
Well that's a silly question.
That you find this a silly question makes me wonder whether you understand mod_perl.
mod_perlservice is an RPC system, not a CGI
system. You will NOT use mod_perlservice to serve up dynamic web pages -
that's mod_perl's job.
mod_perl is for writing RPC, too. As well as anything else you can serve over HTTP et al (and almost any other protocol for v2). If your complaint about existing RPC was simplicity, why did you write something that duplicates mod_perl, limiting its application, rather than just write Perl modules that run under mod_perl to implement your own protocol (as have XML-RPC and SOAP Perl modules)? Why write another embedded interpreter?
No, mod_perlservice will be used to create
applications that need to call remote subs and object-methods. mod_perl
CGI doesn't provide support for marshaling and unmarshaling aggregates;
try passing an array of hashes of arrays of integers efficiently using
CGI, it's improbable. mod_perlservice is for distributed applications that
need to pass and retrieve complex data structures, it is not for simple
forms and content-based html apps.
Despite the fact that I don't know what "mod_perl CGI" is supposed to describe, everything you describe is already done (and in many heavy production environments) with mod_perl + SOAP/XML-RPC Perl modules. Again, I don't think you have a grasp what mod_perl is or does.
So, I've been a bit of a Frankenstein, sewing mod_perlservice together
from the best elements of all the systems out there. Now we have a
scalable, secure, practical, clean, fast, and robust webservices system.
Be happy.
Great. But we have that already in mod_perl + RPC modules.
On the other hand I understand the emotion. You may have felt threatened
by a new embedded perl system on Apache. I hope I have allayed your fears
since mod_perlservice doesn't threaten your work, but instead complements
it.
Nobody feels threatened. Many of us have a need for what you have provided, but found that need met a while ago.
I wrote mod_perlservice because there was nothing out there that satisfied
my requirements.
Again, if your "requirements" were avoiding existing, standardized RPC solutions, OK. But why not use mod_perl to write your system?
It has saved me hundreds of hours while developing my own applications. I hope it will save you time and effort too. I would be happy to answer any other questions you may have, and hope you give mod_perlservice a warm welcome into the GPL world.
This is the mod_perl list. It (part of it) doesn't understand why you wrote a clone to do something we can already do in ways that are proven and standard. That doesn't mean it isn't welcome in the GPL world. It may be valuable to many (and some on this list have expressed that already), but I didn't get it.
- Dan
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
