I haven't thought in detail about this, but if we go such a way we should think of improving the resolve() method of the resource resolver in some way. Today, when a request comes in, the full path is used to find the resource, it's then shortened until an existing resource is found. If we have a request which targets the resource and the accept header defines the extension/selector, then there is no need for such an expensive search mechanism anymore.
Regards Carsten 2014-04-07 7:59 GMT-06:00 Felix Meschberger <fmesc...@adobe.com>: > Hi > > Ok, it is not exactly arbitrary logic. Turns out that content types of the > style > > > application/someformat+somesyntax > > are pretty common (see [1], [2]). Also when talking about REST-ful APIs I > expect some application on the other (client) side and this will in general > not come with a list of content types but with a single one asking for a > concrete representation. > > To have a plugin, you need to define and export an API and you have to > take care about backwards compatibility and evolution. I don't exactly see > where such a travel would lead to right now. > > As to other headers: This is about content type negotiation which involves > as per the HTTP spec the Accept header. The Accept-Language header is for > the language to be used for the representation of the resource but does not > have an influence on the content type. > > Regards > Felix > > [1] http://www.iana.org/assignments/media-types/media-types.xhtml > [2] > https://github.com/osgi/design/blob/master/rfcs/rfc0189/rfc-0189-Http_Service_Updates.pdf?raw=true > > Am 07.04.2014 um 11:20 schrieb Julian Sedding <jsedd...@gmail.com>: > > > I agree with Bertrand. Generally, I'm in favor of supporting the Accept > header. > > > > However coding an arbitrary logic into Sling Engine (or some other > > core bundle) does not sound good to me. > > > > The benefits of a pluggable solution would be > > - preservation of modularity and > > - the implementation of some "special" logic could live in a "contrib" > > bundle, where it's easier to drop support, if the idea turns out to be > > not so good. > > - other headers, e.g. Accept-Language, could also be easily supported. > > > > Regards > > Julian > > > > > > On Mon, Apr 7, 2014 at 10:13 AM, Bertrand Delacretaz > > <bdelacre...@apache.org> wrote: > >> On Mon, Apr 7, 2014 at 9:58 AM, Felix Meschberger <fmesc...@adobe.com> > wrote: > >>> ...I would prefer to not go over board, at least not initially, and > keep it simple and covering simple use cases.... > >> > >> I like simple but what I object to is burning this into the Sling core > >> - what you suggest is based on somewhat arbitrary rules (single > >> content-type etc) which I don't feel good burning into the core. An > >> extension point for setting selectors + extensions is not rocket > >> science. > >> > >> -Bertrand > > -- Carsten Ziegeler cziege...@apache.org
