You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Nathan Torkington <gn...@oreilly.com> on 2002/12/11 21:58:18 UTC

Perl Cookbook modperl chapter

I need some people with brains (instead of the warm gray mush filling
my head, the effects of becoming an editor) to look over the first 1/3
or so of a mod_perl chapter for the upcoming Perl Cookbook.  I need
people to read the work for accuracy.  If you're interested, send me
mail: <gn...@oreilly.com>.

I also need help on content.  I'm not competing with Geoff, Randy, and
Paul's excellent book (mod_perl Developer's Cookbook)--they have 630
pages to cover way more topics than I do.  Their book will always be
the definitive place for a hard-core mod_perl developer to go--in
fact, I'll have them in the See Also sections of the Perl Cookbook.
But I need to cover 15-20 topics that most people of beginning to
intermediate mod_perl use will encounter.

Current recipe list:
  [gnat:~] grep head1 Ora/pcb2/ch21.pod 
  =head1 Introduction
  =head1 Authenticating in mod_perl
  =head1 Setting Cookies in mod_perl
  =head1 Accessing Cookie Values from mod_perl
  =head1 Redirecting the Browser from mod_perl
  =head1 Interrogating Headers in mod_perl Handlers
  =head1 Accessing Form Parameters from mod_perl
  =head1 Receiving Uploaded Files in mod_perl

All suggestions appreciated.

Thanks,

Nat


Re: Perl Cookbook modperl chapter

Posted by Thomas Eibner <th...@stderr.net>.
On Wed, Dec 11, 2002 at 01:13:30PM -0800, Nick Tonkin wrote:
> Obviously you (or ORA) _are_ competing with "mod_perl Developer's
> Cookbook" ... 

Why wouldn't they be? They have "Writing Apache modules with Perl and C"
after all. And with Stas' and Eric's book on the way (www.modperlbook.org)
they already have two books (soon hopefully).

> If ORA wanted to cover mod_perl they should not have let Geoff & co. get
> away to another publisher.

Maybe they felt that the book(s) they already have signed for will/would
saturate the market? A publisher can only justify a certain amount of
books on each topic.

[Don't really want to go into wheter or not mod_perl should be covered
in gnat's book, but if they have decided to include it they are
certainly within their rights to do so. If you don't like that, just
don't buy the book?]

-- 
  Thomas Eibner <http://thomas.eibner.dk/> DnsZone <http://dnszone.org/>
  mod_pointer <http://stderr.net/mod_pointer> <http://photos.eibner.dk/>
  !(C)<http://copywrong.dk/>                  <http://apachegallery.dk/>
          Putting the HEST in .COM <http://www.hestdesign.com/>

Re: Perl Cookbook modperl chapter

Posted by Geoffrey Young <ge...@modperlcookbook.org>.

Paul Lindner wrote:
> Hi,
> 
> I only speak for myself, but I am happy to see mod_perl covered in the
> Perl Cookbook.  Why you ask?  I see the inclusion of mod_perl helping
> increase the size of the mod_perl "pie".  A rising tide lifts all
> boats.  

I totally agree - at this stage in the game, the more quality books 
that cover mod_perl, the better for those of us that want to get paid 
to use and/or develop it.

> 
> I'm not too worried about the content.  I'm sure it will be top-notch.
> Consider that the Perl Cookbook already gives you good coverage of
> several complex domain specific areas: DBI, LWP, CGI, Sockets, Tk,
> etc.

and kudos to Nat for adding mod_perl as a topic at all.  it's 
difficult to decide which topics to cover in a work, especially one 
with such broad coverage as the Perl Cookbook.  having a chapter 
dedicated to mod_perl is not only an honor for the application we all 
love, but is bound to increase its overall exposure.

> 
> I'll be very happy if the Perl Cookbook gets the novice mod_perl
> programmer started and then leads them to the mpDC, which is really an
> intermediate to advanced work.

of course, I also consider it an honor that Nat and ORA have decided 
to mention our book at all - as a publisher competing in many of the 
same areas as Sams, ORA certainly is not required to do so.  but the 
friendliness that (usually :) surrounds the members of our community 
is part of what makes it strong as well as a fun project to be 
involved in.

--Geoff


Re: Perl Cookbook modperl chapter

Posted by Stas Bekman <st...@stason.org>.
Paul Lindner wrote:
> Hi,
> 
> I only speak for myself, but I am happy to see mod_perl covered in the
> Perl Cookbook.  Why you ask?  I see the inclusion of mod_perl helping
> increase the size of the mod_perl "pie".  A rising tide lifts all
> boats.  

I second that. And just like Paul, I only speak for myself.

We need more coverage/crossreference for mod_perl in places where people don't 
know/use mod_perl yet. If Nat's chapter gives plenty of crossreferences to the 
eagle book, cookbook and our new book, it's a goodness.

I'd like to think of Nat's chapter as a teaser, to get the reader all excited 
about mod_perl. So you should a simple auth recipe and say, to learn about 
more complex implementation, see Chapter XXX Book YYY. Now if that reader is 
not really interested in getting to know mod_perl, chances are that he would 
never have bought Book YYY. But if Nat's chapter raised enough curiosity for 
that person to go and buy Book YYY, that's a goodness!

Also please don't forget that the majority of mod_perl users use or at least 
start with *only* Apache::Registry and Apache::PerlRun, so just covering these 
two meaning to bring many more converts to mod_perl, by just letting them know 
that it takes a few minutes to make your perl/cgi scripts fly. Do they need 
more than that? Time will show.

To me what's important is to have as many people as possible *know* about 
mod_perl and its strengths (and weaknesses I guess ;). Because if people don't 
know about mod_perl they obviously won't buy mod_perl books.

The real problem with mod_perl books not selling as well as they could is the 
availability of the online documentation, which certainly doesn't cover the 
cool things in the cookbook and the eagle books, but is good enough for many 
purposes. So I was thinking to help the sales of our book when it hits the 
shelves in March 2003, we should pull the documentation site down for a few 
months and redirect everybody to http://modperlbook.org/ ;) (...for those who 
miss the smiley, I'm joking of course)

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: Perl Cookbook modperl chapter

Posted by Paul Lindner <li...@inuus.com>.
Hi,

I only speak for myself, but I am happy to see mod_perl covered in the
Perl Cookbook.  Why you ask?  I see the inclusion of mod_perl helping
increase the size of the mod_perl "pie".  A rising tide lifts all
boats.  

I'm not too worried about the content.  I'm sure it will be top-notch.
Consider that the Perl Cookbook already gives you good coverage of
several complex domain specific areas: DBI, LWP, CGI, Sockets, Tk,
etc.

I'll be very happy if the Perl Cookbook gets the novice mod_perl
programmer started and then leads them to the mpDC, which is really an
intermediate to advanced work.

My only concern?  If the Perl Cookbook gets any larger I might throw
out my back carrying it around :)  

-- 
Paul Lindner    lindner@inuus.com   ||||| | | | |  |  |  |   |   |

    mod_perl Developer's Cookbook   http://www.modperlcookbook.org/
         Human Rights Declaration   http://www.unhchr.ch/udhr/

Re: Perl Cookbook modperl chapter

Posted by Gunther Birznieks <gu...@eXtropia.com>.
Nick,

I think you raise valid points that I think Nathan and the reviewers 
should take on board when they do this chapter and subsequently review it.

However...

1) I believe that rather than entirely naysay that some common cookbook 
items can be covered in a mod_perl chapter, I would prefer to see what 
Nathan et al come up with rather than discourage them from trying at all.

Will it be "futile" as you suggest? Maybe. But then Nathan and the 
reviewers can choose to cut the chapter.  

Will it be too complex and therefore cause problems for readers? Maybe. 
But I think I would trust Nathan and his reviewers to judge after it's 
done. And again, there is the option of always cutting that chapter as 
mentioned above.

In my past writing life, I've cut plenty of chapters when after seeing a 
whole book, deciding that they didn't fit (or worse, where it just was a 
bad chapter I wrote). I suspect Nathan has done the same in his lifetime 
and I would trust his professionalism in this manner.

In other words, I think we should trust that Nathan et al have been 
writing/editing for a long time.

Can they make mistakes? Yes. No one is perfect. But I also trust that 
their experience will allow them to come up with something for this 
chapter which will suit a market need. And if it doesn't, to not use 
that material.

 But I think it would be sad not to try at all since there could be 
benefits to this chapter.

2) Will mpdc lose sales? I suppose so. Short-term maybe.

But then should Stas stop publishing his book? MacEachern and Stein 
theirs? Surely they also overlap with mpdc. And there will be other 
books by other publishers that will overlap with mpdc as well.

I suppose that I feel like I am more of an economic optimist than you.

While short-term, it may appear that more mod_perl books being released 
would cause fewer sales in a market that is "fixed", long-term, I 
believe having more written material about mod_perl will actually help 
the market.

Provided it is done well, I think a chapter in TPC that covers mod_perl 
explicitly is a good idea also for spreading mod_perl community advocacy 
and learning.

Nick Tonkin wrote:

>On Wed, 11 Dec 2002, Nathan Torkington wrote:
>
>  
>
>>Actually, we do cover mod_perl--we published the Eagle book, "Writing
>>Apache Modules ..." way back in 1999.
>>    
>>
>
>Yes, I have had my now dog-eared copy since then :)
>
>  
>
>>There's no way that 20 recipes in the Perl Cookbook will compete with
>>the what, 250? in the mod_perl Developer's Cookbook.  Especially when
>>the introduction and each recipe points the reader to the mpDC.  The
>>Perl Cookbook has over a hundred thousand readers.  I want to push as
>>many as I can onto the mpDC.  If that's competing, then I can only say
>>that you have a strange sense of competition :-)
>>    
>>
>
>Ahem, well, without wanting to get into a fruitless argument about this
>part, I might say that you have a strange idea of how to push people onto
>their book. At close to $50 a pop, I know I'd think twice about purchasing
>the mpDC if I'd shelled out for the Perl Cookbook and it had a section on
>mod_perl. I venture to say Geoff et al will see less overall sales, rather
>than more, if the PCB has a mod_perl section. This notwithstanding the
>fact that _some_ people _will_ no doubt have their appetite whetted and
>move on to the definitive mpDC. (Of course there's nothing definitive
>about Perl, that's the whole point about TMTOWTDI, right?)
>
>  
>
>>>Trying now to cover highly complex topics like "Authenticating in
>>>mod_perl" in a recipe in a chapter of the Perl cookbook is
>>>futile. It will only serve to oversimplify and lead novices into a
>>>false sense of competence.
>>>      
>>>
>
>This was really my point.
>
>  
>
>>The Perl Cookbook has never pretended to be the definitive guide to
>>anything it covers (have you seen the Perl Cookbook?  I recommend
>>it :-).  Each recipe includes references to definitive sources of
>>information (manpages, web sites, and other books).
>>    
>>
>
>I have also owned the Perl Cookbook since it came out. It's very useful as
>exactly what it says: a cookbook. You can turn to it for a recipe to
>accomplish a small, simple task which you guess others may have tackled
>before you. You can also use it as a tutorial, if you choose to, by
>studying each chapter as a whole. I do not believe that mod_perl lends
>itself to the former, and I think that the mpDC more approaches the
>latter. One can go look up a recipe, true, but it is useless without a
>pretty thorough prior understanding of mod_perl. So, I stand by my
>prediction that just putting a few mod_perl recipes in the PCB will lead
>more than a few people into more problems than solutions.
>
>While I've been writing this reply a few people have responded to your
>request for content suggestions. Stacked handlers, among other things
>... I think it just goes to show that there can be no successful trivial
>coverage of mod_perl. (That's why the Eagle book, and the mpDC, are so
>good.)
>
>- nick
>
>~~~~~~~~~~~~~~~~~~~~
>Nick Tonkin   {|8^)>
>
>
>
>
>
>
>
>  
>

Re: Perl Cookbook modperl chapter

Posted by Nick Tonkin <ni...@rlnt.net>.
On Wed, 11 Dec 2002, Nathan Torkington wrote:

> Actually, we do cover mod_perl--we published the Eagle book, "Writing
> Apache Modules ..." way back in 1999.

Yes, I have had my now dog-eared copy since then :)

> There's no way that 20 recipes in the Perl Cookbook will compete with
> the what, 250? in the mod_perl Developer's Cookbook.  Especially when
> the introduction and each recipe points the reader to the mpDC.  The
> Perl Cookbook has over a hundred thousand readers.  I want to push as
> many as I can onto the mpDC.  If that's competing, then I can only say
> that you have a strange sense of competition :-)

Ahem, well, without wanting to get into a fruitless argument about this
part, I might say that you have a strange idea of how to push people onto
their book. At close to $50 a pop, I know I'd think twice about purchasing
the mpDC if I'd shelled out for the Perl Cookbook and it had a section on
mod_perl. I venture to say Geoff et al will see less overall sales, rather
than more, if the PCB has a mod_perl section. This notwithstanding the
fact that _some_ people _will_ no doubt have their appetite whetted and
move on to the definitive mpDC. (Of course there's nothing definitive
about Perl, that's the whole point about TMTOWTDI, right?)

> > Trying now to cover highly complex topics like "Authenticating in
> > mod_perl" in a recipe in a chapter of the Perl cookbook is
> > futile. It will only serve to oversimplify and lead novices into a
> > false sense of competence.

This was really my point.

> The Perl Cookbook has never pretended to be the definitive guide to
> anything it covers (have you seen the Perl Cookbook?  I recommend
> it :-).  Each recipe includes references to definitive sources of
> information (manpages, web sites, and other books).

I have also owned the Perl Cookbook since it came out. It's very useful as
exactly what it says: a cookbook. You can turn to it for a recipe to
accomplish a small, simple task which you guess others may have tackled
before you. You can also use it as a tutorial, if you choose to, by
studying each chapter as a whole. I do not believe that mod_perl lends
itself to the former, and I think that the mpDC more approaches the
latter. One can go look up a recipe, true, but it is useless without a
pretty thorough prior understanding of mod_perl. So, I stand by my
prediction that just putting a few mod_perl recipes in the PCB will lead
more than a few people into more problems than solutions.

While I've been writing this reply a few people have responded to your
request for content suggestions. Stacked handlers, among other things
... I think it just goes to show that there can be no successful trivial
coverage of mod_perl. (That's why the Eagle book, and the mpDC, are so
good.)

- nick

~~~~~~~~~~~~~~~~~~~~
Nick Tonkin   {|8^)>






Re: Perl Cookbook modperl chapter

Posted by Nathan Torkington <gn...@oreilly.com>.
Nick Tonkin writes:
> Obviously you (or ORA) _are_ competing with "mod_perl Developer's
> Cookbook" ... 
>
> If ORA wanted to cover mod_perl they should not have let Geoff & co. get
> away to another publisher.

Actually, we do cover mod_perl--we published the Eagle book, "Writing
Apache Modules ..." way back in 1999.  We have Stas and Eric's book
coming out in 2003 (March?  April?).  It busts my nut that we didn't
publish Geoff's, Randy's, and Paul's book, but that's the way the dice
fall.

There's no way that 20 recipes in the Perl Cookbook will compete with
the what, 250? in the mod_perl Developer's Cookbook.  Especially when
the introduction and each recipe points the reader to the mpDC.  The
Perl Cookbook has over a hundred thousand readers.  I want to push as
many as I can onto the mpDC.  If that's competing, then I can only say
that you have a strange sense of competition :-)

If we were going to compete head-to-head with the "mod_perl
Developer's Cookbook", O'Reilly would publish the "mod_perl Cookbook".
We've done it before (PHP Cookbook vs PHP Developer's Cookbook).  We
don't have plans to do that, and I'd fight them if we did.  Geoff et
al.'s book is very good, and I want to help their sales not hurt them.

> Trying now to cover highly complex topics like "Authenticating in
> mod_perl" in a recipe in a chapter of the Perl cookbook is
> futile. It will only serve to oversimplify and lead novices into a
> false sense of competence.

The Perl Cookbook has never pretended to be the definitive guide to
anything it covers (have you seen the Perl Cookbook?  I recommend
it :-).  Each recipe includes references to definitive sources of
information (manpages, web sites, and other books).

Nat


Re: Perl Cookbook modperl chapter

Posted by Iain 'Spoon' Truskett <ia...@dellah.org>.
* Ron Savage (ron@savage.net.au) [12 Dec 2002 10:19]:

[...]

> Having 2 books which can both be casually, if incorrectly, called The
> mod_perl Cookbook, is asking for endless (minor) trouble. A distinct
> name would be a distinct advantage.

Given there's already "XML and Perl" and "Perl & XML" (I must admit I
was amused when someone publicising the former called it the latter);
and the myriad combinations of "Perl", "CGI" and "Web" in titles; I
don't think "Perl Cookbook" and "mod_perl Developer's Cookbook" are not
sufficiently distinguished.

Of course, people will call both 'the cookbook', but no doubt we'll be
able to spot which one they mean by the question. mod_perl will be only
one chapter in "Perl Cookbook".


cheers,
-- 
Iain.

Re: Perl Cookbook modperl chapter

Posted by Raf <ra...@joshua.dreamthought.com>.
On Wed, 11 Dec 2002, Nathan Torkington wrote:

> I need some people with brains (instead of the warm gray mush filling
>
> I also need help on content.  I'm not competing with Geoff, Randy, and
>
> Current recipe list:
>   [gnat:~] grep head1 Ora/pcb2/ch21.pod
>   =head1 Introduction
>   =head1 Authenticating in mod_perl
>   =head1 Setting Cookies in mod_perl
>   =head1 Accessing Cookie Values from mod_perl
>   =head1 Redirecting the Browser from mod_perl
>   =head1 Interrogating Headers in mod_perl Handlers
>   =head1 Accessing Form Parameters from mod_perl
>   =head1 Receiving Uploaded Files in mod_perl

how about:

	* How to Bench Mark in mod_perl
	* Using TT2 in Modperl and why it's so much better than
everything else? ;) Apache::Template's plugin and go?

	* How to prepare my legacy cgi scripts to run under
Apache::Registry
	* Setting up proxying to a mod_perl server
	* Using Apache::Dispatch to relate handlers to uris.
	* Separating presentation, business logic and control? (PageKit?)
	* Moving your code to work under mod_perl 2?
	* uri encoded sessions?
        * using soap transport through mod_perl? Soap::Transport::HTTP, or
whatever..
	* internal and external redirects
	* Why am I getting 2 http headers sent?
	* Using .. bored now.
	* debugging

That sort of thing.

r.



Re: Perl Cookbook modperl chapter

Posted by Nick Tonkin <ni...@rlnt.net>.
Nat,

Obviously you (or ORA) _are_ competing with "mod_perl Developer's
Cookbook" ... 

If ORA wanted to cover mod_perl they should not have let Geoff & co. get
away to another publisher.

Trying now to cover highly complex topics like "Authenticating in
mod_perl" in a recipe in a chapter of the Perl cookbook is futile. It will
only serve to oversimplify and lead novices into a false sense of
competence. They'll then show up on this list demanding to know why their
hacks on your recipes do not function as expected.

I do not believe you will do any service to mod_perl or to your readers by
glossing over how large a field of study mod_perl is. It's almost as bad
as the "Teach Yourself Perl in 24 Hours" title put out by Geoff's
publisher.

I urge you to rethink this plan.

- nick

~~~~~~~~~~~~~~~~~~~~   
Nick Tonkin   {|8^)>


On Wed, 11 Dec 2002, Nathan Torkington wrote:

> I need some people with brains (instead of the warm gray mush filling
> my head, the effects of becoming an editor) to look over the first 1/3
> or so of a mod_perl chapter for the upcoming Perl Cookbook.  I need
> people to read the work for accuracy.  If you're interested, send me
> mail: <gn...@oreilly.com>.
> 
> I also need help on content.  I'm not competing with Geoff, Randy, and
> Paul's excellent book (mod_perl Developer's Cookbook)--they have 630
> pages to cover way more topics than I do.  Their book will always be
> the definitive place for a hard-core mod_perl developer to go--in
> fact, I'll have them in the See Also sections of the Perl Cookbook.
> But I need to cover 15-20 topics that most people of beginning to
> intermediate mod_perl use will encounter.
> 
> Current recipe list:
>   [gnat:~] grep head1 Ora/pcb2/ch21.pod 
>   =head1 Introduction
>   =head1 Authenticating in mod_perl
>   =head1 Setting Cookies in mod_perl
>   =head1 Accessing Cookie Values from mod_perl
>   =head1 Redirecting the Browser from mod_perl
>   =head1 Interrogating Headers in mod_perl Handlers
>   =head1 Accessing Form Parameters from mod_perl
>   =head1 Receiving Uploaded Files in mod_perl
> 
> All suggestions appreciated.
> 
> Thanks,
> 
> Nat
> 
> 




Cookie-free authentication

Posted by Geoffrey Young <ge...@modperlcookbook.org>.

Ron Savage wrote:
> On Wed, 11 Dec 2002 13:58:18 -0700, Nathan Torkington wrote:


[snip]


> Some of us are trying to implement authentication/login/logout where, 
> if at all possible, cookies are not to be used. A cookie-free 
> discussion would be most welcome.

I've done a bit of preliminary work with using Digest authentication to accomplish this - 
see Session.pm in Apache::AuthDigest, the latest copy of which can be found here

http://www.modperlcookbook.org/~geoff/modules/Apache-AuthDigest-0.022.tar.gz

it's fairly new interface, and I've only toyed with it (though there is _some_ 
documentation :).  however, it seems to me that (for  clients that can support this 
implementation of Digest, which seems to be just about everyone but MSIE) the nonce 
provides exactly the kind of state information that is required for login/logout 
authentication.

of course, it trades cookies for that pop-up box (again), so if you're looking for 
cookiless, HTML form based logins, then it's probably not what you want.

--Geoff


Re: Perl Cookbook modperl chapter

Posted by David Wheeler <da...@wheeler.net>.
On Wednesday, December 11, 2002, at 03:17  PM, Ron Savage wrote:

> Having 2 books which can both be casually, if incorrectly, called The
> mod_perl Cookbook, is asking for endless (minor) trouble. A distinct
> name would be a distinct advantage.

Nat's book is _The Perl Cookbook_, not _The mod_perl Cookbook_, and is 
the *original* cookbook. He wrote the book on cookbooks, you could say.

:-)

David

-- 
David Wheeler                                     AIM: dwTheory
david@wheeler.net                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e
                                                Jabber: Theory@jabber.org


Re: Perl Cookbook modperl chapter

Posted by Ron Savage <ro...@savage.net.au>.
On Wed, 11 Dec 2002 13:58:18 -0700, Nathan Torkington wrote:

Nathan

>I also need help on content.  I'm not competing with Geoff, Randy,

Some of us are trying to implement authentication/login/logout where, 
if at all possible, cookies are not to be used. A cookie-free 
discussion would be most welcome.

Having 2 books which can both be casually, if incorrectly, called The 
mod_perl Cookbook, is asking for endless (minor) trouble. A distinct 
name would be a distinct advantage.
-- 
Cheers
Ron Savage, ron@savage.net.au on 12/12/2002
http://savage.net.au/index.html