Hi Felix > As to other headers: This is about content type negotiation which involves as > per the HTTP spec the Accept header.
The HTTP 1.1 spec defines the following headers for content-negotiation, I quote: "Accept (section 14.1), Accept- Charset (section 14.2), Accept-Encoding (section 14.3), Accept- Language (section 14.4), and User-Agent (section 14.43)" (see section 12.1 Server-driven Negotiation [0]). Additionally, an implementation is free to vary the response based on any aspect of the request. I understand that you are trying to solve your use-case and I like the idea of supporting content-negotiation in Sling. What I don't want, however, is another ad-hoc solution baked into the core of Sling - I fear that these make Sling harder to maintain, refactor and enhance. Regards Julian [0] http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html On Mon, Apr 7, 2014 at 3:59 PM, Felix Meschberger <fmesc...@adobe.com> wrote: > 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 >
