On 23 Sep 2009, at 13:38, Alexander Klimetschek wrote:
On Wed, Sep 23, 2009 at 13:22, Ian Boston <i...@tfd.co.uk> wrote:
yes I agree that at c2, after all processing is performed, no
resource is
found and, in addition the patch only modifies the behavior of c2.
Ok, so we can agree that the patch won't break existing things. This
leaves the open point a conceptual one, as you note...
we should qualify that, it wont break anything in Sling because there
is nothing that binds to NonExsistantResource, but it will break
anything that binds to NonExistantResource outside Sling, as a
resource type since the content of NonExistingResource has changed.
(the path)
But thats not a good enough reason to reject the patch... more below.
What I don't see justification for, is parsing the path into
selectors,
extensions etc when we have no evidence what is the right parsing.
The patch adopts a convention as justification for the parsing but
IIUC that
convention hasn't been adopted in a,b or c1
...which is right to question. My justification of bringing in a
convention into the parsing is because I think that what is gained is
so useful, that we can live with that convention.
Also, I think it's not an arbitrary convention, but one that follows
for the majority of selector/extension cases. And when considering
that a request to a non-existent resource is typically made *very
specifically* to that URL, we even get a 100% match (because the
server gives clients a certain URL to POST to).
For example (the same as given in SLING-864), to build an importer
servlet for eg. a special file format such as icalendar files (ics),
you would like to do a POST or PUT onto a non-existent resource:
POST /content/calendar.ics
Now if you want to update the file, you do the exact same POST, but
now going the way over the existing resource (but you could use the
same servlet for that, registered under non-existent resource type and
the calendar resource type):
POST /content/calendar.ics
And later you get it via the corresponding export servlet
GET /content/calendar.ics
The problem is that since in the first case the resource does not
exist yet, you currently (ie. w/o the patch) cannot register anything
under the ics extension for non-existing resources. That's why I put
this parsing "convention" into the patch, as it matches the typical
and most-often used case for extensions and selectors.
These are strong overriding reasons to apply this patch.
On this basis I am +1, even it it does change API behavior and break
other code.
Thanks for taking time to work this through.
Ian
IMHO, either the patch should go wide and adopt the convention
throughout or
it should avoid imposing a convention leaving it to things that
*might* be
able to operate on the non existent resource.
It's right that for other special cases the convention might seem
arbitrary, but without the patch they would be lost as well. You can
still apply your custom handling if you want to follow another
convention by simply registering as the default servlet for
non-existing resources and take the plain request URI while ignoring
the pre-parsed selectors and extensions.
Summary: no existing code is broken, and no convention is forced upon;
but if you like the convention, you gain a lot.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetsc...@day.com
