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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 3:58 PM To: [EMAIL PROTECTED] 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 -- 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
