Re: mod_perlservice? Heck Yeah!

[prev] [thread] [next] [Date index for 2004/11/27]

I think it's great that you are proud of your work. Criticism will make  
your work better.

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