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
