Re: SLING-117: don't go up the path in ResourceResolver for GET requests, and get rid of suffixes?

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Freitag, den 30.11.2007, 15:59 +0100 schrieb Bertrand Delacretaz:
> Hi,
> 
> I think recursively going up the path in the
> MicroslingResourceResolver can lead to confusion and redundant GET
> URLs.

Agreed. It also makes resource resolution very heavy - each path is
tested multiple times, costing performances etc.

> Do we really need suffixes? I'm still a bit confused about their goals
> for GET requests.

Not sure, whether we use them, sometimes, they may be helpful.

> Maybe we could simplify the Resource resolution, here's a suggested
> example where only /content/foo exists:
> 
>   /content/foo -> HTTP status code 200
>   /content/foo.html -> 200, extension=html
>   /content/foo.print.a4.html -> 200, extension=html, selectors=print.a4
>   /content/foo/bar -> 404
>   /content/foo.html/bar -> 404
> 
> This would be for GET/HEAD requests only, as POSTs need the extra path
> components.
> 
> Basically, the only separators allowed after the path of an existing
> resource would be dots.

Agreed. I would start from this point and suggest the following
algorithm:

(1) test the path unmodified, if found, exit
(2) find the last dot in the path, everything starting with the next
slash
     is the suffix. If there is no dot, fail.
(3) from the rest of the path elements are cut off at dots until a slash
is
     reached. As soon as a node is found, that node is taken. the
elements
     cut off (except the last) are the selectors, the last element is
the
     extension.
(4) If no node is found searching upto the slash, a GET request fails
404.
    Any other request may be checked for the parent path. If anything is
    found ok, else 404.

So for an existing /content/foo node:
  /content/foo -> HTTP status code 200
  /content/foo.html -> 200, extension=html
  /content/foo.print.a4.html -> 200, extension=html, selectors=print.a4
  /content/foo/bar -> 404 for GET, else further processing, suffix=/bar, extension ??
  /content/foo/bar/bar -> 404 always
  /content/foo.html/bar -> 200, extension=html, suffix=/bar

Regards
Felix

Re: SLING-117: don't go up the path in ResourceResolver for GET requests, and get rid of suffixes?

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Dienstag, den 04.12.2007, 10:33 +0100 schrieb Bertrand Delacretaz:
> >   /content/foo/bar -> 404 for GET, else further processing, suffix=/bar, extension ??
> 
> extension is empty in this case, right?

I would say so, yes. What I am not sure, is whether this is acceptable ?

> 
> >   /content/foo/bar/bar -> 404 always
> 
> so to create that node you'd first have to create /content/foo/bar ?

Yes.

> 
> For an unsafe request (i.e. not a GET) we might also say
> 
>   /content/foo/bar/bar -> 404 for GET, else further processing,
> suffix=/bar/bar, extension empty
> 
> How does WebDAV handle this case? I think in WebDAV you have to create
> the folders one by one?

I am not sure, whether this is specified in WebDAV. In a filesystem, it
is like this.

The question is, whether we would want to create intermediate nodes
automagically or not. In a filesystem, this is trivial because
intermediate nodes must be folders. In a repository, this is not trivial
because intermediate nodes may be almost anything.

Regards
Felix

Re: SLING-117: don't go up the path in ResourceResolver for GET requests, and get rid of suffixes?

[Bertrand Delacretaz <bd...@apache.org>]

On Nov 30, 2007 6:49 PM, Felix Meschberger <fm...@gmail.com> wrote:

> ...So for an existing /content/foo node:
>   /content/foo -> HTTP status code 200
>   /content/foo.html -> 200, extension=html
>   /content/foo.print.a4.html -> 200, extension=html, selectors=print.a4

ok with all of these

>   /content/foo/bar -> 404 for GET, else further processing, suffix=/bar, extension ??

extension is empty in this case, right?

>   /content/foo/bar/bar -> 404 always

so to create that node you'd first have to create /content/foo/bar ?

For an unsafe request (i.e. not a GET) we might also say

  /content/foo/bar/bar -> 404 for GET, else further processing,
suffix=/bar/bar, extension empty

How does WebDAV handle this case? I think in WebDAV you have to create
the folders one by one?

>   /content/foo.html/bar -> 200, extension=html, suffix=/bar

ok

-Bertrand

Re: SLING-117: don't go up the path in ResourceResolver for GET requests, and get rid of suffixes?

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Dienstag, den 04.12.2007, 11:30 +0100 schrieb David Nuescheler:
> An example URI could like this:
> /mypage/upload.spool/my.pdf
> 
> Where the .spool extension would kick-off the spool.esp script
> that then delegates after checking the suffix with the
> originalFilename delegates
> to the WebDAV GET. This allows to expose "my.pdf" still as the "filename"
> of the browser download.

This would break my algorithm of [1]:

> (2) find the last dot in the path, everything starting with
>     the next slash is the suffix. If there is no dot, fail.

Of course changing it to say "find the _first_ dot in the path" would
fix this, assuming there are no further dots along the path.

Regards
Felix

[1]
http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01073.html

Re: SLING-117: don't go up the path in ResourceResolver for GET requests, and get rid of suffixes?

[David Nuescheler <da...@day.com>]

Hi Bertrand,

> > Am Freitag, den 30.11.2007, 15:59 +0100 schrieb Bertrand Delacretaz:
> > > ...Do we really need suffixes? I'm still a bit confused about their goals
> > > for GET requests.
> > Not sure, whether we use them, sometimes, they may be helpful....
> That sounds much like YAGNI to me ;-)
I know of a usecase for the suffix that is very common.

let's assume i would like to let a user upload an arbitrary file into an
nt:resource node. To be able to provide a sensible filename for
the later download I would also store the original filename along side.

Now since the browser uses the last segment of the URL as the filename
on the downloaders local disk, I need to have an option to append that
filename at the tail end of the URI to allow for a useable filename on the
client....

An example could work like this:

/mypage
- title = pdfpage title
- text = this is my pdf
+ upload (nt:resource)
- originalFilename = my.pdf

An example URI could like this:
/mypage/upload.spool/my.pdf

Where the .spool extension would kick-off the spool.esp script
that then delegates after checking the suffix with the
originalFilename delegates
to the WebDAV GET. This allows to expose "my.pdf" still as the "filename"
of the browser download.

regards,
david

Re: SLING-117: don't go up the path in ResourceResolver for GET requests, and get rid of suffixes?

[Bertrand Delacretaz <bd...@apache.org>]

On Dec 4, 2007 11:21 AM, Felix Meschberger <fm...@gmail.com> wrote:
> > > > ...Do we really need suffixes?....

> ...OTOH how would you support creating a node /content/foo/bar below the
> existing node /content/foo ? Would you require the POST (or whatever
> method) method to extract the relative path "bar" from the request URI ?...

You're right, suffixes are useful for POST requests, and we're using
them already.

And I just had a chat with David who mentioned using suffixes for GET
requests, for example in case a file is uploaded as an nt:resource at
/content/mypage/upload, and it is useful to have
/content/mypage/upload/originalname.pdf as the download URL, so that
downloaders get the right filename.

That's two use-cases where suffixes are useful, thanks for clarifying
that - that's enough for me to want to keep them, I just needed to
have concrete cases.

-Bertrand

Re: SLING-117: don't go up the path in ResourceResolver for GET requests, and get rid of suffixes?

[Felix Meschberger <fm...@gmail.com>]

Am Dienstag, den 04.12.2007, 10:27 +0100 schrieb Bertrand Delacretaz:
> On Nov 30, 2007 6:49 PM, Felix Meschberger <fm...@gmail.com> wrote:
> 
> > Am Freitag, den 30.11.2007, 15:59 +0100 schrieb Bertrand Delacretaz:
> > > ...Do we really need suffixes? I'm still a bit confused about their goals
> > > for GET requests.
> >
> > Not sure, whether we use them, sometimes, they may be helpful....
> 
> That sounds much like YAGNI to me ;-)

OTOH how would you support creating a node /content/foo/bar below the
existing node /content/foo ? Would you require the POST (or whatever
method) method to extract the relative path "bar" from the request URI ?

Regards
Felix

Re: SLING-117: don't go up the path in ResourceResolver for GET requests, and get rid of suffixes?

[Bertrand Delacretaz <bd...@apache.org>]

On Nov 30, 2007 6:49 PM, Felix Meschberger <fm...@gmail.com> wrote:

> Am Freitag, den 30.11.2007, 15:59 +0100 schrieb Bertrand Delacretaz:
> > ...Do we really need suffixes? I'm still a bit confused about their goals
> > for GET requests.
>
> Not sure, whether we use them, sometimes, they may be helpful....

That sounds much like YAGNI to me ;-)

Any other opinions?