httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: cvs indecision
Date Fri, 01 Dec 2000 02:08:48 GMT
I hate travelling -- got back from Austin exhausted and sickly.

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:
> >...
> > What I am thinking of doing is rebuilding the repository as if it were
> > a standard source tree (not a dual build/source tree), as follows:
> > 
> >    httpd-2.0/
> >              build/                 [src/build and src/helpers]
> >              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)

> >              include/
> >              modules/
> >                      aaa/           [access authentication and auth DBs]
> >                      generators/    [mod_asis, mod_cgid, etc.]
> >                      filters/       [mod_include, etc.]
> >                      loggers/       [mod_log_config, etc.]
> >                      mappers/       [mod_alias, mod_rewrite, etc.]
> >                      metadata/      [mod_cern_meta, mod_user_track, etc.]
> >                      cache/
> >                      dav/
> >                      proxy/
> >                      experimental/
> 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

                 server/                [src/main]

but then people will start complaining about dav and proxy protocols.

I would prefer to keep front-end modules in the server directory and
back-end modules in the modules directory.  Regardless, mod_echo
would be a sibling to http [wtf was it doing in modules/standard?].
Maybe the directory should be called back-end instead of modules?

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.

> >              srclib/
> >                      apr/           [autocheckout? via &apr-httpd-2.0]
> >                      aputil/        [what greg just created and src/ap]
> >                      expat-lite/    [autocheckout?]
> >                      pcre/          [autocheckout?]
> We have local mods to the above two packages, so an autocheckout isn't going
> to work for these.
> >                      sdbm/          [autocheckout?]
> 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.

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).

> >                      openssl/       [autocheckout?]
> >                      zlib/          [autocheckout?]
> >              support/
> >              test/
> > 
> Where would src/os/ go? I would suggest server/os/. Note that it continues
> to exist because we have os-specific functionality that lives in there (for
> example, Win32 service registration and handling). This is app-level
> functionality, rather than portability stuff, so it goes here rather than in
> APR.

I don't believe in os-specific directories.  Anything that is necessary
for portability should be in APR, and anything else should be located
according to function.  This may mean that there are foo_win32.c files
that are selectively compiled, but one of the main things that makes
the core configuration a mess right now is the lack of abstraction.

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.


View raw message