You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by mi...@ivorycity.com on 2004/11/27 00:57:31 UTC
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
Re: mod_perlservice? Heck Yeah!
Posted by Dan Brian <da...@brians.org>.
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
Re: mod_perlservice? Heck Yeah!
Posted by Eric <ef...@kwinternet.com>.
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
Re: mod_perl marketing
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I've used it a lot -- my copy is a bit beat up.
excellent :)
>
> Well, from one satisfied reader, here's a big "Thank You!" to Geoffrey,
> Paul Lindner, and Randy Kobes for writing that book!
sure.
> Don't you mean 02/2002? My copy says first printing January 2002.
it was published in late january. I preordered a copy for myself from
amazon, just to see when it was _really_ available, and it came the first
week of february.
> Also, maybe the publisher (SAMS) hasn't given you the support you deserve.
Sams have actually been great. but the way this industry works, you just
can't sell a book that isn't already selling.
anyway, I didn't want to make this about our book in particular. but when I
hear about people who _still_ think that mod_perl is some CGI interface I
get really bothered, since there is so much out there (books, articles,
documentation, conference talks, etc) that tell the real story but that
people consistently overlook.
--Geoff
--
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
Re: mod_perl marketing
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-11-30 at 10:25 -0600, Frank Wiles wrote:
> I think the API is what really separates mod_perl from other similar
> technologies. And I think we all agree that this is what needs to be
> stressed more to the public to gain better adoption.
Actually, I don't really agree. I just thought it was surprising that a
knowledgeable programmer with apache and Perl expertise would not know
about it. An article about radical new stuff in mp2 like protocol
handlers would be pretty cool though.
- Perrin
--
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
RE: mod_perl marketing
Posted by Clayton Cottingham <dr...@telus.net>.
> >
> I'd bet that mod_perl's slower growth rate over the past
> couple of years has a lot to do with Apache2 and no
> production mod_perl2.
>
Good Point
> Thus, people wanting Apache2 would immediately screen out
> mod_perl. I think that's an awfully big hill to climb to
> convince new adopters, i.e.
> either stick with Apache1 or try a non-production mod_perl2.
>
> Fortunately, with the imminent arrival of production
> mod_perl2, the growth rates of mod_perl will probably go up.
> (I'm guessing from hints in this thread that an announcement
> is imminent, right? Heck, I'm already using it in production.)
>
> If possible, an rpm version of mod_perl2 ready at the same
> time as the announcement of a press release would probably
> help new adopters to try it out.
>
> Take care,
>
> Kurt
>
This is a crucial point for sure, making sure your marketing and software
are timed together
--
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
Re: mod_perl marketing
Posted by Kurt Hansen <kh...@charityweb.net>.
Clayton Cottingham wrote:
>Well then we need to understand, via surveys etc, where all these
>mod_perl'ers came from, why they choose to use mod_perl
>
>>>From there we should have a better understanding of where we come from
>
>And who to market to, and how we have to educate those markets in order to
>get them to even take a look at mod_perl
>
>
I'd bet that mod_perl's slower growth rate over the past couple of years
has a lot to do with Apache2 and no production mod_perl2.
Thus, people wanting Apache2 would immediately screen out mod_perl. I
think that's an awfully big hill to climb to convince new adopters, i.e.
either stick with Apache1 or try a non-production mod_perl2.
Fortunately, with the imminent arrival of production mod_perl2, the
growth rates of mod_perl will probably go up. (I'm guessing from hints
in this thread that an announcement is imminent, right? Heck, I'm
already using it in production.)
If possible, an rpm version of mod_perl2 ready at the same time as the
announcement of a press release would probably help new adopters to try
it out.
Take care,
Kurt
--
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
RE: mod_perl marketing
Posted by Clayton Cottingham <dr...@telus.net>.
Being a programmer that has worked at two marketing companies I'll add my
two cents
First of all I must say at how little effort goes into mod_perl marketing
and how much knowledge is out here
As say compared to web3d.org whose marketing efforts mostly fall into
/dev/null
With that said I find it particularly peculiar that most of these
consortiums/open source projects dedicated little to no energy into
developing marketing plans.
Getting articles and writting books are a great way to increase awareness
and to drive the market through low level marketing strategies
There are other ways, one thing I see of import in this thread is the fact
that mod_perl is for mod_perlers, to increase our market we cant preach to
the converted, so where are the heathen coders?!!!!!
Well then we need to understand, via surveys etc, where all these
mod_perl'ers came from, why they choose to use mod_perl
>From there we should have a better understanding of where we come from
And who to market to, and how we have to educate those markets in order to
get them to even take a look at mod_perl
> -----Original Message-----
> From: Frank Wiles [mailto:frank@wiles.org]
> Sent: November 30, 2004 8:26 AM
> To: Dan Brian
> Cc: modperl@perl.apache.org
> Subject: Re: mod_perl marketing
>
> On Tue, 30 Nov 2004 09:10:32 -0700
> Dan Brian <da...@brians.org> wrote:
>
> > I would suggest that future mp2 articles (on perl.com and
> elsewhere)
> > take some time to explain the Apache API and why it is by
> far the best
> > choice for Perl server development, before diving into the
> particulars
> > of accomplishing something with it.
>
> I've got an article coming out in SysAdmin Magazine in January that
> is more about the power of the Apache API than about the normal
> response phase workings.
>
> I think the API is what really separates mod_perl from other similar
> technologies. And I think we all agree that this is what
> needs to be
> stressed more to the public to gain better adoption.
>
> ---------------------------------
> Frank Wiles <fr...@wiles.org>
> http://www.wiles.org
> ---------------------------------
>
>
> --
> 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
Re: mod_perl marketing
Posted by Frank Wiles <fr...@wiles.org>.
On Tue, 30 Nov 2004 09:10:32 -0700
Dan Brian <da...@brians.org> wrote:
> I would suggest that future mp2 articles (on perl.com and elsewhere)
> take some time to explain the Apache API and why it is by far the best
> choice for Perl server development, before diving into the particulars
> of accomplishing something with it.
I've got an article coming out in SysAdmin Magazine in January that
is more about the power of the Apache API than about the normal
response phase workings.
I think the API is what really separates mod_perl from other similar
technologies. And I think we all agree that this is what needs to be
stressed more to the public to gain better adoption.
---------------------------------
Frank Wiles <fr...@wiles.org>
http://www.wiles.org
---------------------------------
--
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
Re: mod_perl marketing
Posted by Dan Brian <da...@brians.org>.
The lack of awareness extends to Apache generally, and not just
mod_perl. Saying that "mod_perl isn't just CGI; it allows Perl coding
to the Apache API" is not really informative, because people don't know
what the Apache API is. (The author that initiated this thread replied
to me privately that his mod_ "doesn't embed the Apache API, is that
possible?", so it appears to be possible to write a mod_ without even
knowing ... ?)
Only 2 years ago I was pitching a "Perl application development" title
to an O'Reilly editor (who shall remain nameless) who asked me why I
thought mod_perl was a "big deal" (since my outline had a heavy
emphasis on it). After explaining what I thought about it, I got a
curious look, followed by the comment, "yeah, we don't think that is
really going places." And to this day, many Perl people still don't
understand how you could build large applications using mod_perl, as
opposed to CGI + templates and PHP (or other HTML markups). Threads
like (http://use.perl.org/~jjohn/journal/20761) still make the mistake
of comparing mod_perl to PHP. mod_perl invites developers to invent new
CMSs, new ways to authenticate, to manage sites, to log data, new ways
to handle content. PHP is for writing web sites. I personally didn't
know whether mod_perl's audience is that much larger than its current
user base; this thread proves it is.
I have used mod_perl 1 since soon after it became available, building
several CMSs, custom markup languages (as have we all), and so on.
Verio's entire line (almost) of web hosting customer interfaces is
built on mod_perl and XSLT. This isn't emerging technology anymore! I
took the dive to mp2 a few months ago, and am astounded by both the
Apache 2 API and its Perl translation. You have all completely outdone
yourselves, and mp is a bigger deal than ever.
I would suggest that future mp2 articles (on perl.com and elsewhere)
take some time to explain the Apache API and why it is by far the best
choice for Perl server development, before diving into the particulars
of accomplishing something with it. Perhaps a "mod_perl for Beginners:
All Your Servers ..." article could be useful, or adapting Randal's
intro talk, or something like that.
In the end though, there's a lot of documentation. The eagle book is
great, and the cookbook was mentioned too. Until people read, there's
not much we can do about 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
Re: mod_perl marketing
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-11-30 at 16:42 +0100, Xavier Noria wrote:
> Amazon.com doesn't run Mason under mod_perl?
Right, they run it under FastCGI.
> Or they don't use Mason
> for the website frontend? For the store?
They do use it for the store, although not every page on every store
they run is Mason. You can usually tell by the URL.
- Perrin
--
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
Re: mod_perl marketing
Posted by Xavier Noria <fx...@hashref.com>.
On Nov 30, 2004, at 4:33 PM, Perrin Harkins wrote:
> On Tue, 2004-11-30 at 10:21 -0500, Kurt Hansen wrote:
>> On the marketing front, doesn't Amazon use mod_perl, at least
>> partially?
>
> No, they use FastCGI. It's a win for Perl, but not for mod_perl
> specifically. Ticketmaster.com, Citysearch.com, and many other big
> ones
> use mod_perl and are pretty vocal about it at tech conferences and
> such.
Amazon.com doesn't run Mason under mod_perl? Or they don't use Mason
for the website frontend? For the store?
Or is it that when you say "such a site runs under mod_perl" people
mean "pure" mod_perl?
-- fxn
--
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
Re: mod_perl marketing
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2004-11-30 at 10:21 -0500, Kurt Hansen wrote:
> On the marketing front, doesn't Amazon use mod_perl, at least partially?
No, they use FastCGI. It's a win for Perl, but not for mod_perl
specifically. Ticketmaster.com, Citysearch.com, and many other big ones
use mod_perl and are pretty vocal about it at tech conferences and such.
- Perrin
--
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
Re: mod_perl marketing
Posted by Kurt Hansen <kh...@charityweb.net>.
Geoffrey Young wrote:
>
>I feel I need to interject here. _all_ of the points you raise to this
>point are well covered in the mod_perl developer's cookbook, which has been
>available since 02/2001. in fact, that's why we wrote it - both to address
>many of the things the mod_perl community had learned since the eagle book
>was written, as well as take the "access to the C API in Perl" road. we
>hardly even mention Registry or CGI (but we do mention how to subclass
>RegistryNG :) and that was very, very on purpose.
>
>the unfortunate situation is that the cookbook suffers from lack of exposure
>(and sales, for that matter) - you obviously understand mod_perl and are
>participating on the list, yet you still didn't know that your issues are
>(and were) well covered with available documentation.
>
>
Really? It hasn't sold well? I've used it a lot -- my copy is a bit beat up.
Well, from one satisfied reader, here's a big "Thank You!" to Geoffrey,
Paul Lindner, and Randy Kobes for writing that book!
Don't you mean 02/2002? My copy says first printing January 2002. Also,
maybe the publisher (SAMS) hasn't given you the support you deserve.
On the marketing front, doesn't Amazon use mod_perl, at least partially?
Maybe you could get some mention or a logo on their site, ya know, as a
way to support the community? Maybe some Easter egg that pops up if you
do a specific search, i.e. something that engineers would have fun
passing around?
Take care,
Kurt Hansen
P.S. I also have the Eagle book and Practical mod_perl and am very
grateful for those as well! Especially recently during a move to
Apache2/mod_perl2
--
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
Re: mod_perl marketing
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> During those projects,
> the only place where I saw it clearly stated that mod_perl is "program
> Apache the way you like in Perl" instead of "CGI on steroids" is the
> Eagle Book - which for the record, is an O'Reilly book titled "Writing
> Apache Modules in Perl and C" by Lincoln Stein and Doug McEachern, and
> the name "Eagle Book" comes from the fact that the cover animal is,
> you guessed it, an eagle
> (http://www.foo.be/docs/tpj/issues/vol4_3/tpj0403-0014.html). Even
> *that* bibliographic data was a pain for me to retrieve from the
> mailing list archive!
>
> Online documentation on anything in the mod_perl guts is very, very
> scarce, and I had to RTFS more than once even to perform basic
> mod_perlish tasks such as writing a subclass of Apache::RegistryNG.
> Even the Eagle Book itself is sub-useful in places (e.g. the infamous
> ass_backwards stuff), and other parts of the Apache API visible from
> mod_perl has to be guessed from the "writing Apache modules in [...]
> C" section. At least this is how things were two years ago:
I feel I need to interject here. _all_ of the points you raise to this
point are well covered in the mod_perl developer's cookbook, which has been
available since 02/2001. in fact, that's why we wrote it - both to address
many of the things the mod_perl community had learned since the eagle book
was written, as well as take the "access to the C API in Perl" road. we
hardly even mention Registry or CGI (but we do mention how to subclass
RegistryNG :) and that was very, very on purpose.
the unfortunate situation is that the cookbook suffers from lack of exposure
(and sales, for that matter) - you obviously understand mod_perl and are
participating on the list, yet you still didn't know that your issues are
(and were) well covered with available documentation.
anyway, at this point, that we wrote a book that nobody seems to be using is
less of a complaint than a simple fact of life, so I guess it doesn't make
sense to discuss it further. just venting a bit...
--Geoff
--
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
Re: mod_perl marketing
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Dominique" == Dominique Quatravaux <do...@idealx.com> writes:
Dominique> On the bright side, you guys are doing quite a good job at keeping
Dominique> mod_perl on the radar of many pointy-haired bosses, and I understand
Dominique> that this marketing crusade cannot but take the CGI-and-performance
Dominique> route when the competition is Java. Still, the techs out there hear
Dominique> about mod_perl's true powers mostly through hearsay.
I just finished transcribing my 90-minute "intro to mod_perl" talk
into a three-part series for Linux Magazine... it's dribbling out
over the next few months, and will be on my website shortly after
the embargo has passed.
It's always been clear to me that the real power of mod_perl wasn't
the content phase... there are so many OTHER cool things that mod_perl
does, and mod_php and mod_cgi and mod_fastcgi can't touch that.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
--
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
mod_perl marketing
Posted by Dominique Quatravaux <do...@idealx.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Perrin Harkins wrote :
| [...] [W]e have to face the fact that someone who knew enough about
| Perl and apache to write an embedded interpreter module still
| thought that mod_perl was some kind of limited CGI replacement.
| This means we are not getting the word out very well, and it's
| distressing.
Sad but true. Although I've yet to take that long-overdue deep dive
into MP2, I consider myself an experienced MP1 hacker (I wrote an HTTP
reverse-proxy in it, and also did most of the effort writing no less
than a web application framework - for those who can grok french or
can use the Babelfish, see
http://conferences.mongueurs.net/2004/talk/6). During those projects,
the only place where I saw it clearly stated that mod_perl is "program
Apache the way you like in Perl" instead of "CGI on steroids" is the
Eagle Book - which for the record, is an O'Reilly book titled "Writing
Apache Modules in Perl and C" by Lincoln Stein and Doug McEachern, and
the name "Eagle Book" comes from the fact that the cover animal is,
you guessed it, an eagle
(http://www.foo.be/docs/tpj/issues/vol4_3/tpj0403-0014.html). Even
*that* bibliographic data was a pain for me to retrieve from the
mailing list archive!
Online documentation on anything in the mod_perl guts is very, very
scarce, and I had to RTFS more than once even to perform basic
mod_perlish tasks such as writing a subclass of Apache::RegistryNG.
Even the Eagle Book itself is sub-useful in places (e.g. the infamous
ass_backwards stuff), and other parts of the Apache API visible from
mod_perl has to be guessed from the "writing Apache modules in [...]
C" section. At least this is how things were two years ago: now that I
am "in the know", I don't need documentation all that much anymore and
therefore my point of view could well be outdated.
On the bright side, you guys are doing quite a good job at keeping
mod_perl on the radar of many pointy-haired bosses, and I understand
that this marketing crusade cannot but take the CGI-and-performance
route when the competition is Java. Still, the techs out there hear
about mod_perl's true powers mostly through hearsay. What about
setting up some tech-oriented wiki to tip the balance backwards for
the rest of us? This would be a great place to link the press releases
to when MP2 final is announced.
- --
Dominique QUATRAVAUX Ingénieur senior
01 44 42 00 08 IDEALX
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBrE5hMJAKAU3mjcsRAtW1AJ9gJzVbogRNck6bWxzkPK+j2CH4yACfccDR
WLhFQoqw1XmbmhvGHewB910=
=4+sn
-----END PGP SIGNATURE-----
--
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
Re: mod_perlservice? Heck Yeah!
Posted by Perrin Harkins <pe...@elem.com>.
On Fri, 2004-11-26 at 18:57 -0500, michaelcollins@ivorycity.com wrote:
> 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.
After seeing the responses from others on the list, hopefully you can
understand why your module came across as a sort of slap in the face
when I saw it on perl.com. The fact that you didn't realize how much
you were duplicating mod_perl functionality means it wasn't intentional
on your part, but then we have to face the fact that someone who knew
enough about Perl and apache to write an embedded interpreter module
still thought that mod_perl was some kind of limited CGI replacement.
This means we are not getting the word out very well, and it's
distressing.
I hope you'll consider creating a version of your module that runs on
mod_perl. It's a powerful and well-tested platform, and we are
generally a pretty helpful bunch when asked.
- Perrin
--
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
Re: mod_perlservice? Heck Yeah!
Posted by Sam Tregar <sa...@tregar.com>.
On Fri, 26 Nov 2004 michaelcollins@ivorycity.com wrote:
> 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.
>
> ...
>
> 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.
How about SOAP? I'm sure the problem you identify with XML-RPC
don't apply to SOAP. I've created SOAP apps which share space with
web-apps and offer multiple modules in a single server.
> Well, why not just use mod_perl?
>
> Well that's a silly question. mod_perlservice is an RPC system, not a CGI
> system.
You just lost me. Clearly mod_perl is not a CGI system. It's a Perl
binding to (nearly) all of Apache, of which an emulated CGI
environment is just a small piece.
> 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.
Application functionality like marshaling and unmarshaling can be
added by modules on top of mod_perl. Take SOAP::Lite, for example.
> 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.
I'm sorry your feelings were hurt. The free software world has never
been a very friendly place. I suppose the best we can hope for is
that every project is judged fairly on its merits.
-sam
--
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