RE: mod_perlservice? Heck Yeah!

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

It would be interesting to see mod_perl and XML-RPC equivalents of the =
examples on www.ivorycity.com.  I'm open to something that is easier.

Just a thought.

Chuck


-----Original Message-----
From: michaelcollins@xxxxxxxxx.xxx [mailto:michaelcollins@xxxxxxxxx.xxx]
Sent: Friday, November 26, 2004 3:58 PM
To: modperl@xxxx.xxxxxx.xxx
Subject: mod_perlservice? Heck Yeah!


Gentlemen,

mod_perlservice rocks. I know because I wrote it.

Let my email explain why I wrote mod_perlservice and why it will provide
obvious benefits to webservices developers.

Why not just use XML-RPC?

XML-RPC is a standalone system (except for the Java-Apache extension). =
If
you need to run your webservices system on port 80, for firewalling =
issues
for instance, you can't also run Apache. That's not ideal. With
mod_perlservice, you can host RPC webservices AND webpages all on one
server! Wow.

mod_perlservice was built to intentionally take advantage of both object
oriented and function oriented programming styles. I'm not sure whether
XML-RPC was designed with that in mind.

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.

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.

Furtherstill, mod_perlservice builds on Apache, the most secure, trusted
and stable platform out there. But I don't need to tell you the benefits
of that. It's why you have mod_perl instead of a standalone Perl-CGI
webserver.

Well, why not just use mod_perl?

Well that's a silly question. 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. 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.

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.

It's all Free and GPL. It was developed by me and I decided to share it
with all of you. I don't understand why some of you might snark at my
work. If you'd ever launched a GPL project of your own, I believe you'd
stop short of criticizing before you know the whole story. I've spent
hundreds of hours contributing something useful to the community that =
I've
received so much from. Every submission should be welcomed.

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.

I wrote mod_perlservice because there was nothing out there that =
satisfied
my requirements. 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.

Thank You.

Michael Collins







--=20
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


        -- 
        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