Hi,
Roy T. Fielding schrieb:
> On Nov 23, 2008, at 1:42 PM, Felix Meschberger wrote:
>> Roy T. Fielding schrieb:
>>> I think that Sling should use a content tree to establish the
>>> root mappings; e.g.,
>>>
>>> /etc/map/{scheme}/{host.port}/{uri_path}
>>>
>>> with the default contents being
>>>
>>> /etc/map/http/example.com.80/
>>> +-- sling:redirect = "http://www.example.com/";
>>> www.example.com.80/
>>> +-- sling:alias = "/example/"
>>> *.example.com.80/
>>> +-- sling:redirect = "http://www.example.com/";
>>> localhost.*/
>>> +-- sling:alias = "/content/"
>>> localhost.*/cgi-bin/
>>> +-- sling:alias = "/scripts/"
>>> localhost.*/gateway/
>>> +-- sling:alias = "http://gbiv.com/";
>>
>> Values for sling:redirect would be used as is for the Location: header
>> of the 302/FOUND response, right ?
>
> Yes, though perhaps it should be a multi-valued property with a
> [ HTTPstatus, URI, ... ]. We should use the same mechanism for all
> types of redirect.
>
> 300 Multiple Choices
> 301 Moved Permanently
> 302 Found
> 303 See Other
> 307 Temporary Redirect
Wouldn't this be two properties, one for the status and one for the URI
ref ? If the status property would not be set, it would default to 302.
What if the value is set to anything other than you listed, e.g. a
non-standard or even an inappropriate one like 404 ?
>
>> Values for sling:alias would be absolute path directing to another
>> resource, an absolute URL pointing to another location inside /etc/map
>> or an URL consisting of host.port and uri_path pointing to another
>> location in the /etc/map/{scheme} subtree of the same scheme. Correct ?
>
> I would make alias a possibly relative JCR path.
> I would make redirect a possibly relative URI reference.
>
> Note that I just made up those sling:alias and sling:redirect names
> based on what they are called in httpd. If they already have a defined
> meaning within sling, then feel free to choose a better name.
ok, then these names might make sense, and we would have to rethink our
use of sling:alias (there is none implemented yet, so we are free to use
it in this context), except in the new sling:ResourceAlias mixin node
type to attach to nodes to assign alternate names.
If we go with sling:alias as the property name in /etc/map for forward
mapping, we would need another name for the property listing alternate
names of nodes - to prevent mixing concepts.
>
>>> The resolver would check the path for a match by walking
>>> down the /etc/map tree. If there is a name match, then continue
>>> following that path. Otherwise, if there is a "*" match, then
>>> follow that path. If neither, then the mapping is defined by the
>>> properties on the last matching node.
>>>
>>> sling:alias is a path mapping (what we call an internal redirect
>>> in httpd because it isn't visible to the client). Note that this
>>> can be very flexible: The last example configures a reverse proxy of
>>>
>>> http://localhost/gateway/ <==> http://gbiv.com/
>>
>> So this would resolve the request for http://localhost/gateway by
>> looking at the properties of /etc/map/http/gbiv.com.80 (for example),
>> right ? Interesting.
>
> Yes, I think, though I would phrase it as resolving all Sling
> requests by following this map toward the proper handler.
>
>>> The advantage here is that the mappings are easily cached without
>>> new code, easily visible to users by looking at the tree, and
>>> versioned just like any other content. If you want to make the
>>> matching even faster, then this /etc/map tree can be walked as a
>>> regular expression and compiled each time the map tree changes,
>>> which is much easier than walking the entire content tree.
>>>
>>> In my opinion, path mappings in the rest of the content tree
>>> should be limited to same-level aliases and external redirects.
>>
>>
>> I think the "mappings" in the actual content would then just be real
>> aliases. For example:
>>
>> /etc/map/http/localhost.*/
>> +-- sling:internalRedirect = "/content/"
>> /content/sample
>> +-- sling:alias = "beispiel"
>>
>> So a request http://localhost/beispiel would be resolved to
>> /content/sample, because ...
>> * http://localhost/ would lead to a internal redirect to /content
>> * "beispiel" would be another name for the node at /content/sample
>
> But that is backwards, in my opinion. We should have a node called
>
> /content/beispiel
>
> that says it is a hard link (alias) for
>
> /content/sample
>
> because sample may be a fixed node type that is either non-modifiable
> or limited in its allowed properties. Does JCR support hard links
> natively in JSR 283? If not, we can use sling:alias.
I defined a mixin node type sling:ResourceAlias, which provides the
sling:alias property and which may be assigned to the resoure which
would take the property.
There are catches with each solution:
My solution, which you call "backwards" is harder to implement in the
resolver since we have to scan the children for any property set as
expected. On the other hand it is easier to manage as a property of the
resource to which it applies and it moves together with the resource.
Your solution (lets call it "forward") is simpler to implement in the
resolver, but we would have to check on each access whether there is a
property set on the resovled resource. But managing the value is more
complicated because when moving the target (move, delete, copy) the
alias still "points" to the old location thus resolution will be failing.
I tend to prefer the "backwards" way.
>
>> External redirects from within the content tree (outside /etc/map) are
>> already possibly today by setting a sling:target property on a resource
>> whose resource type is "sling:redirect".
>
> Ah, okay, so instead of the sling:redirect property we can just use
> the sling:redirect nodetype with properties for sling:target (URI-ref)
> and sling:status (HTTP status code)? That's fine with me.
That would be a good addition. Right.
>
>> Did I understand you correctly ?
>
> I think so -- I just didn't know the right names.
>
>> Regarding the naming of the things. With your proposal and the existing
>> sling:redirect resource type, we would have the following names:
>>
>> * sling:redirect : HTTP redirect target
>> * sling:alias : internal redirect if inside /etc/map,
>> alternate name if not inside /etc/map
>> * sling:target : HTTP redirect target for sling:redirect resource
>>
>> How about changing this as follows:
>>
>> * sling:target : HTTP redirect target for /etc/map setup and for
>> sling:redirect resource
>> * sling:internalTarget : internal alias for /etc/map setup
>> * sling:alias : alternate name for the same node
>>
>> IMHO this would convey clearly the concepts behind these properties.
>
> Hmm, I suppose it would be confusing to use sling:target for both
> redirect and alias targets. What I suggest is
Agreed. This is also what Bertrand Delacretaz said. Thus the current
prototype state does not use target but sling:redirect for an external
redirect and sling:internalRedirect for what you call alias.
>
> sling:redirect (node type)
> |- sling:target (URI reference)
> `- sling:status (HTTP status code for redirect type)
Actually the node type is called "sling:Redirect" but the resource type
is sling:redirect.. I agree, that sling:status is a worth-while addition
to this.
>
> sling:alias (node type) [or whatever hardlinks have become in JSR283]
> `- sling:path (JCR path relative to alias path)
I am not currently up to date with respect to hard links in JSR 283. I
am also not sure (as explained above regarding backwards vs. forward),
whether we need this.
>
> ....Roy
>
