On Nov 19, 2007, at 11:57 AM, Jukka Zitting wrote:
On Nov 18, 2007 5:01 PM, David Nuescheler <[EMAIL PROTECTED]> wrote:
Personally, I would rather just go for a straight, more direct
extension-based
resolution than engaging in the whole mimetype business.
+1
Though, on a tangent, I'm wondering if we could achieve the same use
cases with just the existing URL-to-JCR-path mapping. For example,
instead of:
.../path/to/document.html
.../path/to/document.pdf
.../path/to/document.json
.../path/to/document.atom
We could do something like this:
.../path/to/document
.../pdf/path/to/document
.../json/path/to/document
.../atom/path/to/document
With actual /pdf, /json, and /atom nodes within the repository to
dispatch the desired processing or rendering functionality. The nice
thing about this approach is that we could more easily have customized
behaviour per subtree:
.../path/pdf/to/document
In fact I'd even consider doing the same for selectors to simplify the
URL mapping process to a direct path walk.
The disadvantage is that it makes a mess of hierarchical access control
and relative links. Very bad. The only time I use that approach is for
language selection, which tends to create its own "locality of
reference"
that is better organized as separate sites/trees of content.
For various reasons (mostly to do with cool URIs being decoupled from
the implementation), it is better to have one exposed URI path like
../path/to/document
with a virtual node that means "indirect to default selectors" or
"indirect to selectors based on content negotiation." Then, a set of
more-specific URIs w/selectors for each variant can be used as the
target of the URI indirection, and also for direct links
to non-negotiated resources.
The only real advantage of mime-type based script resolution is that
it gives more flexibility for old URIs to be creatively redirected
to newer implementations. A better solution is to simply build-in
a URI indirection mechanism that can set on a per-URI basis.
....Roy
