In a short time we will start the doc project for 2.0. My idea is to
prepare a well thought-out layout for the documentation before we even
start to put the actual doc bits inside, so we won't end up with the
ad-hoc pile of info which the current guide is.
One of the first issues I want to raise is whether we want all-in-one
guide or having two guides:
1. Users guide (think current guide).
2. Developers guide (think most of the eagle book).
The Users guide is for those who want to run their code under mod_perl.
The Developers guide is about writing 3rd party modules tightly tied with
mod_perl API, debugging, troubleshooting.
Of course there is a lot of in common between the two, but the Users guide
is supposed to be somewhat simpler and shorter to get people running.
Whereas the Developer guide is all about details, more complicated things,
that most of the users won't want/need to know.
So stuff like end user Auth(z)? techniques will go into the Users guide,
but writing 3rd party modules probably more belongs to the latter guide.
For example techniques for using XS/Inline/Swig would be nice to have in
the Developers guide, but they definitely don't fit into the Users guide.
Separating the two also means that we can have different groups of people
with different skill-sets working on different guides. This will allow
people with less hard-core skills still contribute a lot by maintaining
the Users guide.
Comments are welcome.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
