From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Saturday, September 01, 2001 10:50 PM
> On Saturday 01 September 2001 20:10, Cliff Woolley wrote:
> >
> > Perhaps modules distributed through official httpd subprojects are more
> > visible/more trusted, but we don't really know one way or the other on
> > that front yet.
>
> I can agree with this, but this is something we need to fix. There are many
> ways to fix it. Fixing modules.apache.org would be a very good first step.
++1, we want to _highlight_ our extra projects at http://httpd.apache.org/more/!
And perhaps provide some links from pages like manual/mod/index.html with a
"Not here? Try the third-party modules, (registered by their authors)
at http://modules.apache.org/"; for completeness.
> Putting every module into the core is NOT the answer to this problem. IMNSHO,
> Apache should be a minamilistic web server. If we don't need it in the core,
> it shouldn't be there. Personally, I would remove mod_dav from the server too,
> because it doesn't implement part of RFC2616.
I was thinking about this. We are discussing if /modules/proxy/ should be readded
to the core tree over at [EMAIL PROTECTED] My observation there is that the
RFC for mod_proxy may be expanded outside of the http schema in the future. We
already have adjunt Connection-Upgrade/tls over http extensions to that RFC. This
argument will give us headaches until we decide some simple rules to add a module
as a core or sub project.
WebDAV isn't a 'done' protocol, and really started out as the WebDA protocol
(versioning deferred until we figure out how it should be described.) I'm sure
it will grow. mod_ssl isn't 'done' either, until we implement the Connection-Upgrade
schema. Not only are some folks in the world bound _never_ to download it (as it
is in conflict with their own laws) but some folks in the world are prohibited by
the US from downloading it (the T5). And it too is supplimented by the TLS RFCs.
One thorn in everyone's side was that mod_proxy implemented a HTTP/1.0 superset,
although the rest of the server was essentially HTTP/1.1.
IMHO, if a modules is on a different standards track (or likely to be extended on
one) it should probably live in it's own subproject.
Who on the proxy team wants to wait for the core to bump a version "just because
proxy wants us to." The proxy team finishes implementation of another extension,
they want to get an alpha/beta/release out the door! If they implement another
proxy-protocol, they want to get that out the door (sftp anyone?)
How about one last example ;-? Lets say SQL support is deemed 'important'. An
httpd-sql subproject might implement several aaa modules, with some additional
support/ apps, to allow SQL stuff. Then they get the hairbrained idea to .htaccess
as a SQL table (for performance.) This project could grow (with a charter of
'extending httpd core file-based mechanisms through a generic SQL layer') as far
as they wanted to take it.
In a perfect world, apache-2.0.26-gold-core.tar.gz contains just the core. Then
give the world apache-2.0.26-gold-all-gold-20010915.tar.gz with all _released_
subprojects effective 2001.09.15 rolled in! The adventurous could try the
apache-2.0.26-gold-all-beta-20010915.tar.gz. Finally, the looney (most folks
that follow this list) can grab apache-2.0.26-gold-all-alpha-20010915.tar.gz
for alpha releases of every module (probably a longer list, since some subprojects
at a given time likely haven't gone gold just yet.)
Subprojects would probably have an easier time with a user of the gold apache core
release, since the bugs are more likely to be _in_ their module, not somewhere
else. Now we stand a (small) chance of keeping up.
Add some decent user support outside of the (sometime now hard-to-reach) nttp
support in comp.infosystems.www.servers. and these could be really useful. With
a [EMAIL PROTECTED], [EMAIL PROTECTED], proxy-users... and actually
make that a really strong system, by using mod_mbox on http://httpd.apache.org/
to allow folks to browse those threads. We must be one of the last strong projects
with _no_ user's list (what's up with that ;-?)
Subprojects shouldn't be our orphans. The give small author groups well deserved
recognition. They need to become our crowning jewels.
Bill
