httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject cvs reorg (was: Re: cvs indecision)
Date Fri, 01 Dec 2000 03:16:50 GMT
On Thu, Nov 30, 2000 at 06:08:48PM -0800, Roy T. Fielding wrote:
> I hate travelling -- got back from Austin exhausted and sickly.

eek. my sympathies...

> On Tue, Nov 28, 2000 at 12:46:47PM -0800, Greg Stein wrote:
> > On Mon, Nov 27, 2000 at 04:04:13AM -0800, Roy T. Fielding wrote:
> > >...
> > >              docs/
> > >                      docroot/       [containing index files in htdocs]
> > >                      conf/          [what is in conf now]
> > >                      icons/         [just the small ones]
> > >                      manual/        [what is now htdocs/manual]
> > 
> > Toss or keep cgi-bin/ ?
> Keep, but renamed.  How about cgi-examples? (or just cgi)

I like cgi-examples. That clarifies their purpose, and their optional use.

> > A protocols section? e.g. where does mod_echo go? And would we put HTTP as a
> > sibling of echo? (rather than server/http/ as you have below)
> I was trying to simplify things so that people working on the front-end
> of the server (the core) would not have to jump separate hierarchies.
> Perhaps it would be better to have
>                  protocols/
>                          echo/
>                          http/
>                          ssl/
>                  server/                [src/main]
>                          mpm/
>                          main.c
>                          buildmark.c
> but then people will start complaining about dav and proxy protocols.

hehe. "but that is just HTTP!" will become a FAQ :-)

But maybe this says that dav and proxy should go there?

> I would prefer to keep front-end modules in the server directory and
> back-end modules in the modules directory.

Seems fine, depending on how you define those terms... is dav a front-end
protocol? or a back-end implementation? (by virtue of leveraging HTTP and
using the modules mechanism)

> Regardless, mod_echo
> would be a sibling to http [wtf was it doing in modules/standard?].

No clue. There was a suggestion somewhere to move it out of there. It is
just that nobody got around to it. Guess we have a chance now :-) Back to
the original point... it would seem that it would go into server/echo/.

Oh. But wait. The reason why I ask about a "protocols" section under
modules/ is because things like mod_echo are modules. There isn't any reason
why HTTP wouldn't be handled as a module (and SSL, too)

So, the question becomes: do we organize solely by function, or do they go
into modules/ because of their implementation mechanism?

> Maybe the directory should be called back-end instead of modules?

Nope. You have modules to do logging, filters, possibly config, etc. I'm not
sure that you can classify all of them as "backend". Also, this kind of
distinguishing characteristic would need to be explained somewhere: "what is
the frontend? how is that different/separate from the backend?"

> My opinion would be different if we distributed the header files based
> on purpose, since then it might make sense to put all of the protocol
> definitions in the same directory as client and server implementations.
> However, since header files are all in the include directory, there
> really isn't much commonality between the front-end and the back-end.

Well, not quite. mod_dav.h lives in modules/dav/main/, and mod_include.h
currently lives in modules/standard/. Each of these need to be exported for
third-party modules to use.

At the moment, this is done by the "install-include" target (to include
mod_dav.h; mod_include.h isn't published yet)

> > There is no canonical SDBM distro, let alone a CVS repository for it. The
> > SDBM in Apache CVS is "ours" for all intents and purposes, and falls under
> > our continued maintenance/development.
> I meant that it would make more sense for these to be their own cvs
> modules on, so that they could be used by multiple projects.
> We would still be maintaining them as "ours", perhaps only as a vendor
> branch for things like openssl and zlib, but I don't see any reason
> to keep them in the httpd cvs module directly.

This is fine. We're ramping up an "aprutil" library right now. That would
hold the portable functionality, but useful for app-building. Things like
MD5 (from APR), and from Apache: src/ap/, src/lib/aputil/, and some pieces
of src/main/. (aprutil took over from where aputil was going to go; so the
new aputil is already obsolete :-)

[ and note: we probably do *not* want to start screwing with CVS vendor
  branches. bad, painful juj (based on my experience while we did that in
  SVN for a while; painful even given that Karl "Karl Knows CVS" Fogel was
  managing the process ]

> There is nothing sacred about srclib -- they are just libraries of
> code used by more than one module (whether that be a mod_whatever or
> some other Apache project).

Can we please codify that in a document about the repository layout? You've
probably missed it, but there has been recent traffic on new-httpd about the
purpose of src/lib/. Is it:

   1) completely separable (from Apache) packages
   2) little bundles of functionality used by Apache, possibly by others

Your statement above tends towards (2).

> I need to restore the old tags to the docs first before I can do any
> moving of files, and that will fill my time tonight.  Let's try to
> get the directories finalized by tomorrow.  I can do whatever move is
> desired after that.  The main thing is that we get the directories
> right, since it is the ridiculous number of empty directories and
> overlapping cvs modules that is killing checkouts right now.

No rush. I much prefer the new organization and clarification about the
repository layout. Whenever it happens is Goodness(tm).


Greg Stein,

View raw message