All I ask is that you kill that center tag on your site :)
I have an aborted project that had been intended to use XML-RPC with PHP being the client, and mod_perl being the server. I am interested in what you are doing, but I am wondering how much use it is for this kind of project if it is not following some standard. On that I am not certain because I know Flash does use XML of some kind, but what about other systems, languages? Would I end up having to write a custom client in PHP in order to use this in place of XML-RPC which comes built in to PHP now days?
I also think it is pretty cool that you have some enthusiasm over your own work, nothing wrong with that!
Thanks,
Eric
At 03:57 PM 11/26/2004, you wrote:
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
-- 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
Lead Programmer
D.M. Contact Management
250.383.8267 ext 229
-- 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
