httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: cvs commit: apache-2.0/src CHANGES
Date Mon, 30 Oct 2000 21:02:36 GMT
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Monday, October 30, 2000 11:12 AM
> 
> > Let me cite my own experiences... had it not been for mod_cgi (a very simple
> > handler with a very similar task) I would have found it difficult to integrate
> > buckets with mod_isapi.  I believe that this module accomplishes the same task
> > at the filter authoring level, a very simple implementation of filters.  I'd
> > argue that we have far more specialized modules with far more limited appeal
> > (focused, if you rather.)
> 
> But that's not the purpose of our modules.  Our modules implement a
> web-server.  If we need examples of how to do things, then we have
> mod_example or the docs.

Then put this in the same directory as mod_example.  mod_example provides an
example of a handler.  Jeff's contribution is an example of an external filter.
I'm -1 on putting every feature but the kitchen sink into a single example :-)

> > I agree we don't roll the kitchen sink, and that it's pretty obscure why one
> > would really use this module (or not, let's let the users prove it.)  But if
> > I'm not using python, perl or php I'm out of luck?  No, this is the basis
> 
> No, you aren't out of luck, but then you should be writing an Apache
> module, not an external filter.

Ok... I'm not using python, perl, php, or c.  Now what :-?  Seriously, external
processors can be very, very useful.  But I'm not as concerned about the actual
performance of this module, just the example it provides.

> > [...] either way, I'd suggest you have lots more modules to boot before we 
> > argue the merits of this one.  
> 
> Then suggest the modules to boot and let's get rid of them.  :-)

Look, I'd argue it takes alot more that 3 +1's to nix a prior, reasoned
decision to include a module.  Folks have come to expect certain things of
the distribution.  Those we have pulled were pulled for good reason (they
were both archaic and their functionallity was moved.)  mod_proxy is an
unusual exception, there is a huge demand and insufficient resources, but
since we are the 'http reference implementation', then we aught to provide
the reference to proxying functions.  Provided we have contributed support
to this by 2.0, it aught to stay, and if we can't provide it we must pull
it out, and acknowledge that we are only a partial reference.

Closing thought on this topic...

Until we get to some level of binary compatibility, it is very unreasonable
to ask users to pull down 15 difference parts from different places, each on
their own timetable, in order to get a functioning server for their app.
To spare users the associated headaches, at a cost of double the size, is
well worth it.  They are running a server, ergo they have a large enough
pipe?  Pipes have multiplied one to three orders of magnitude, and you are
concerned with doubling the size of 2.0?  I am not a proponent of MS's 
interpretation of Moore's law ("The size of a given program multiplies
exponentially every 18 months.")  But I'm also not obsessed with the issue
(excepting useless build cruft like precompiled headers).






Mime
View raw message