You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modules-dev@httpd.apache.org by Richard Hubbell <ri...@yahoo.com> on 2007/07/24 18:36:40 UTC

modules dev docs, porting docs

Just finished a porting project of a module from
1.3->2.2.4 and I found information scattered all over
and eventually found what I needed.  I thought that I
just didn't have the "right" link or something to the
docs. I guess my expectations may have been too high. 
It seems like a project like httpd.apache with it's
millions of users wold have a much more mature set of
docs.  The httpd 2.2.4 doxygen stuff was hosted
off-site and those were a life-saver. The APR docs
helped a bunch too.  But the docs don't seem to match
the popularity and ubiquity of the project. Anyone
disagree? Or have I missed something?
I will help with docs where I can.


       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 

Re: modules dev docs, porting docs

Posted by Arturo 'Buanzo' Busleiman <bu...@buanzo.com.ar>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Tim Bray wrote:
> The saving grace is that the httpd & modules code is generally very
> transparent and readable.  In every case, when I was puzzled as to (a)
> what does apr_furgle_brolly() really do?  or (b) how do I accomplish
> XXX? I was able to track the answer down by poking around *.[ch].

Yes, that's true. But taken form another point of view, a more "architectural" point of view let's
say, I can't believe I had to go through mod_perl's EXCELLENT documentation (1) to understand WHY
apache is not allowing extra headers when I write a fully-rewriting input connection filter for
mod_openpgp. (3)

Of course, we have amazing books, like Nick Kew's, but still!

References:

1 - http://perl.apache.org/docs/2.0/user/handlers/filters.html
2 - http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Input_Filters
3 - http://linux-consulting.buanzo.com.ar/2007/07/apache-frustration-p.html

- --
Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica
SHOW DE FUTURABANDA - Sabado 18 de Agosto 2007 (Speed King, Capital Federal)
Entradas anticipadas a traves de www.futurabanda.com.ar - Punk Rock Melodico


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpjOpAlpOsGhXcE0RCpk6AJ97XPHAS6AaCKDmYQxKi54Mfd5jcgCcCGFj
B9hi8b/7Cp/cU5nHNuaK+/g=
=Ju0e
-----END PGP SIGNATURE-----

Re: modules dev docs, porting docs

Posted by Richard Hubbell <ri...@yahoo.com>.
--- Tim Bray <Ti...@Sun.COM> wrote:

> On Jul 24, 2007, at 9:36 AM, Richard Hubbell wrote:
> 
> > Just finished a porting project of a module from
> > 1.3->2.2.4 and I found information scattered all
> over
> > and eventually found what I needed.  I thought
> that I
> > just didn't have the "right" link or something to
> the
> > docs. I guess my expectations may have been too
> high.
> > It seems like a project like httpd.apache with
> it's
> > millions of users wold have a much more mature set
> of
> > docs.  The httpd 2.2.4 doxygen stuff was hosted
> > off-site and those were a life-saver. The APR docs
> > helped a bunch too.  But the docs don't seem to
> match
> > the popularity and ubiquity of the project. Anyone
> > disagree? Or have I missed something?
> > I will help with docs where I can.
> 
> As one who wrote some modules for 1.3 a few years
> back, and recently  
> returned to write one for 2.2, I found the
> documentation to be pretty  
> weak, and (what's worse) mod_example is simply
> incorrect; it should  
> be fixed or removed.  If I get some cycles to invest
> in docs, I'll  
> start with mod_example on the theory that examples
> are the best  
> tutorials.

Yep, bad docs are worse than none.  I only looked at
code that was working.

> 
> The saving grace is that the httpd & modules code is
> generally very  
> transparent and readable.  In every case, when I was
> puzzled as to  
> (a) what does apr_furgle_brolly() really do?  or (b)
> how do I  
> accomplish XXX? I was able to track the answer down
> by poking around  
> *.[ch].

Yep, used the source, plenty, but that's rarely
enough.
I also tried to post here, but was unable to.  I never
discovered why. I think I subscribed 2 weeks ago and
the two previous messages I sent to this list went
missing.  No response from the list owner, zippo.
There oughta be more than one moderator/owner.

List owner, you there?
> 
> Use the Source, Luke.  -Tim
> 



       
____________________________________________________________________________________
Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

Re: modules dev docs, porting docs

Posted by Tim Bray <Ti...@Sun.COM>.
On Jul 24, 2007, at 9:36 AM, Richard Hubbell wrote:

> Just finished a porting project of a module from
> 1.3->2.2.4 and I found information scattered all over
> and eventually found what I needed.  I thought that I
> just didn't have the "right" link or something to the
> docs. I guess my expectations may have been too high.
> It seems like a project like httpd.apache with it's
> millions of users wold have a much more mature set of
> docs.  The httpd 2.2.4 doxygen stuff was hosted
> off-site and those were a life-saver. The APR docs
> helped a bunch too.  But the docs don't seem to match
> the popularity and ubiquity of the project. Anyone
> disagree? Or have I missed something?
> I will help with docs where I can.

As one who wrote some modules for 1.3 a few years back, and recently  
returned to write one for 2.2, I found the documentation to be pretty  
weak, and (what's worse) mod_example is simply incorrect; it should  
be fixed or removed.  If I get some cycles to invest in docs, I'll  
start with mod_example on the theory that examples are the best  
tutorials.

The saving grace is that the httpd & modules code is generally very  
transparent and readable.  In every case, when I was puzzled as to  
(a) what does apr_furgle_brolly() really do?  or (b) how do I  
accomplish XXX? I was able to track the answer down by poking around  
*.[ch].

Use the Source, Luke.  -Tim