On Dec 13, 2007 3:13 AM, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > On Dec 12, 2007, at 1:10 PM, Bertrand Delacretaz wrote: > > How about > > > > /content/some/resource.html/s:version:1.4/s:lang:fr/somefile.pdf > > > > where suffixes starting with s: are reserved for Sling usage? > > yuck. A general principle of web design is that you shouldn't > be able to tell how a server is implemented by looking at the URI,...
Right...I had this vague feeling that my example URLs started to look like...no I'm not telling what, but something ugly ;-) > ...What we should do is separate the mapping into a sequence > of extensibility hooks and only define the delegation points. > For example, we know that the path up to the last JCR node > is handled by Sling, so just define everything after that > point (i.e., EXTRA_PATH) as input to a sequence of registered > filters for that resource (where the sequence is itself a > node identified by a property on the resource node, either > explicitly or by default based on node type)... Ok, we can reuse the existing sling:resourceType property, which currently points to a path where processing scripts are found: that path could contain a node that defines this sequence of filters. > ..That would > allow both fine-grained handling of the extra path and > flexibility for legacy resources... Ok - that means having some additional info (besides scripts) in the directory pointed to by sling:resourceType, and nothing prevents this in the current design. IIUC this means we don't need to do anything unless someone needs access to specific versions, as Juanjo suggests: we could then implement a mechanism like you propose, but we already have the "suffix acquisition" and "resource points to a configuration/script area" parts, so we should be fine. -Bertrand
