what is apache? (Re: Small direction change for APR's file I/O routines.)

[Dean Gaudet <dg...@arctic.org>]

On Sun, 9 Jan 2000 rbb@apache.org wrote:

> 
> > > actually better than an error condition would be a compile-time
> > > conditional such as HAS_UNIX_UID, HAS_UNIX_GID, or something like that.  
> > > this was an area which was painful in NSPR too -- there was no way to
> > > implement mod_userdir, for example.
> > 
> > A compile time option would work just as well.
> 
> I take that back.  I am not sure a compile time option is as good.  I am
> worried about portability in the future, and having people add
> HAS_WINDOWS_(UID|GID).  The same goes for any other platform.  This was
> easy enough to deal with when we were hiding the internals.  People didn't
> like hiding the internals, so I opened them up.  Now, we are going to
> start putting back all the #ifdef's that APR was designed to take out.
> Except, that this time, we are changing the conditions from the obvious
> #ifdef WIN32 to #ifndef HAS_UNIX_UID (which may be true for BeOS or
> MacOSX).  I need to think about this more, but I definately am back to
> sitting on the fence about compile time options versus defined constants.
> :-)

my problem is that i don't know anything at all about access rights,
users, groups, etc. on other platforms... so i couldn't figure out an
abstraction which would let things such as mod_userdir become portable.

ok so the truth is, this is an edge of functionality where we get to
debate on "what is apache?"  and "who are the users of apache?"

maybe we just want to declare some modules to be unix specific and be done
with it... that'd be really nice.

'cause really something like mod_userdir is a unix thing.

i think the core technology in apache is akin to "HTTP routing", and i
know some others agree with this.  get requests off the wire and delivered
to the correct module as fast as possible.

the other stuff is "packaging" -- consider our endless iterations on
mod_autoindex/mod_include.  each time we iterate we get a little bit
closer to a full programming language.  but there's other groups of folks
(for example php) that have already done this far better than we will.
i've not used php, but i imagine it's really easy to do the equivalent of
all the mod_autoindex ReadMe, and Header stuff, plus format the directory
indicies into tables with whatever fancy colours and gifs you want... and
you don't need to patch the server to change the format.

it might make sense to pick a few modules for 2.0 which are the core
technology, decide that we'll provide a portability layer which
encompasses that, and then leave the rest in os-specific modules. spin off
a side-project which is "apache classic for unix" which includes the
mod_userdir, mod_autoindex, mod_include, and suexec stuff.

Dean

Re: what is apache? (Re: Small direction change for APR's file I/Oroutines.)

[David Reid <ab...@dial.pipex.com>]

I'm forced to agree with Dean that a few of the modules would be better off
as OS specific.  Making them specific would be useful and would make
rewriting them into the 2.0 world easier, whilst giving a server that was
easier to tailor.  The windows port might gain by having a different set of
modules that each has it's own config directives.  Certainly platforms such
as OS2 and BeOS probably would, and this fits very nicely with my recent
proposal for configuration files!  (Sorry couldn't resist that :-))

david
----- Original Message -----
From: "Dean Gaudet" <dg...@arctic.org>
To: <ne...@apache.org>
Sent: Sunday, January 09, 2000 10:51 PM
Subject: what is apache? (Re: Small direction change for APR's file
I/Oroutines.)


> On Sun, 9 Jan 2000 rbb@apache.org wrote:
>
> >
> > > > actually better than an error condition would be a compile-time
> > > > conditional such as HAS_UNIX_UID, HAS_UNIX_GID, or something like
that.
> > > > this was an area which was painful in NSPR too -- there was no way
to
> > > > implement mod_userdir, for example.
> > >
> > > A compile time option would work just as well.
> >
> > I take that back.  I am not sure a compile time option is as good.  I am
> > worried about portability in the future, and having people add
> > HAS_WINDOWS_(UID|GID).  The same goes for any other platform.  This was
> > easy enough to deal with when we were hiding the internals.  People
didn't
> > like hiding the internals, so I opened them up.  Now, we are going to
> > start putting back all the #ifdef's that APR was designed to take out.
> > Except, that this time, we are changing the conditions from the obvious
> > #ifdef WIN32 to #ifndef HAS_UNIX_UID (which may be true for BeOS or
> > MacOSX).  I need to think about this more, but I definately am back to
> > sitting on the fence about compile time options versus defined
constants.
> > :-)
>
> my problem is that i don't know anything at all about access rights,
> users, groups, etc. on other platforms... so i couldn't figure out an
> abstraction which would let things such as mod_userdir become portable.
>
> ok so the truth is, this is an edge of functionality where we get to
> debate on "what is apache?"  and "who are the users of apache?"
>
> maybe we just want to declare some modules to be unix specific and be done
> with it... that'd be really nice.
>
> 'cause really something like mod_userdir is a unix thing.
>
> i think the core technology in apache is akin to "HTTP routing", and i
> know some others agree with this.  get requests off the wire and delivered
> to the correct module as fast as possible.
>
> the other stuff is "packaging" -- consider our endless iterations on
> mod_autoindex/mod_include.  each time we iterate we get a little bit
> closer to a full programming language.  but there's other groups of folks
> (for example php) that have already done this far better than we will.
> i've not used php, but i imagine it's really easy to do the equivalent of
> all the mod_autoindex ReadMe, and Header stuff, plus format the directory
> indicies into tables with whatever fancy colours and gifs you want... and
> you don't need to patch the server to change the format.
>
> it might make sense to pick a few modules for 2.0 which are the core
> technology, decide that we'll provide a portability layer which
> encompasses that, and then leave the rest in os-specific modules. spin off
> a side-project which is "apache classic for unix" which includes the
> mod_userdir, mod_autoindex, mod_include, and suexec stuff.
>
> Dean
>