forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject on second thought: forrest must start dynamic?
Date Sat, 23 Feb 2002 17:52:07 GMT
I've reviewed my phases proposal and I think I overlooked something.

There are two major things that we can't do (easily, at least) with a
static snapshot:

 1) have a clean URI space
 2) perform user-agent-depending transformations

to do this statically, we could generate a bunch of .htaccess files with
lots of mod_rewrite rules to perform those things.

I consider the above two *very* important for a few big reasons:

 1) a clean URI space (for 'clean' I normally mean 'well-designed' so
this normally reflects in 'extension-less') forces people to see URIs as
contracts and not as filesystem mappings.

Let's make a quick test: which URIs you would link and expect them to be
there in a few years?

 http://xml.apache.org/
 http://xml.apache.org/forrest/home
 http://xml.apache.org/forrest/home.wml
 http://xml.apache.org/forrest/home?type="wap"

Your answer doesn't matter because you can't tell: a cleanly designed
URI space can be broken more often than badly designed one, URIs are
passive they don't take care of themselves.

What is important is *your* perception of the solidity of the URI.

If we design a URI space such as

 http://*.*.*/*/download/*/*_*
 http://*.*.*/*/download/*/*_*(_*(_*)?)?.tar.gz
 http://*.*.*/*/download/*/*_*(_*(_*)?)?.zip
 http://*.*.*/*/download/*/*_*(_*(_*)?)?.sig

where 

 {1} -> project
 {2} -> domain
 {3} -> suffix
 {4} -> codebase
 {5} -> major.minor
 {6} -> codebase
 {7} -> major.minor.release-additional
 {8} -> additional info (bin|src|docs|...)
 {9} -> platform (win32|freebsd|linux|darwin|solaris|...)

you can be pretty damn sure that people will start see the consistency,
understand the methodology behind and appreciate the fact that they can
find what they want by simply 'constructing' the URI themselves.

[note that the actual location of things on the file system could be
totally different from the above]

And the first, extension-less download should provide textual
information on the release (such as the announement, README or
equivalent), will also give you a list of available downloads for this
release along with general WARNINGS, pitfalls and so on.

Interesting enough, the above works with no changes with

 http://*.*.*/download/*/*/*_*
 http://*.*.*/download/*/*/*_*(_*(_*)?)?.tar.gz
 http://*.*.*/download/*/*/*_*(_*(_*)?)?.zip
 http://*.*.*/download/*/*/*_*(_*(_*)?)?.sig

where /download is now a project-wide folder and lists all the available
projects.

[today we do this with file system synlinks... talking about hacks!]

Also, I think that standardizing a URI space such as

 http://xml.apache.org/forrest/install

down into

 http://*.*.*/*/install

is a good thing, but in order to do this (and check consistency) a
static snapshot is not enough, unless you want to get crazy with
symlinks + mod_magic + mod_rewrite... while with Cocoon requires you *NO
ABSOLUTE* changes to what generates the static snapshot.

This, however, brings a mirroring problem to the picture: I'm pretty
sure that if Apache requires java+apache+tomcat+cocoon installed in
order to provide mirroring, nobody would.

That's a fact.

So, either we forget about clean URIs or we come up with some
mod_rewrite hacks while performing the static snapshots.

The same thing can be said for the user-agent reaction, which is a must
unless we want to waste several years of our life to fix
incompatibilities between browser versions.

Anyway, having static snapshots for mirroring purposes is a must or
Apache will never adopt forrest globally.

comments?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


Mime
View raw message