On Wed, Sep 23, 2009 at 13:22, Ian Boston <[email protected]> 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... > 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. > 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 [email protected]
