Stefan,
> > As serving files from directories on the file systems is
> > not really in our scope,
>
> I don't recall suggesting it was ...
I didn't mean to imply that. If mapping directories was indeed in our scope,
we would have had to handle file extensions for sure. This was my only
point.
> > I think that when users need to specify a special media type that
> > they want to get, they have two options:
> >
> > 1) Adjust their "Accept" header to force the conneg to return a
> > specific
> > representation
>
> I agree this is the clean way ...
OK
> > 2) Rely on a query parameter like "media=application/xml"
> >
>
> ... while this seems to be just as good or bad as the other
> suggestion.
>
> > Note that the ".xml" extension is more ambiguous than "application/
> > xml" or
> > "application/blinksale-xml".
> >
>
> I agree.
OK
> > We could even automate the translation of the "media" parameter
> > into an
> > "Accept:" header like we do in the Restlet framework:
> > http://www.restlet.org/documentation/1.0/api/org/restlet/service/
> > TunnelServi
> > ce.html
> >
>
> Neat, but I'm not entirely sure I would like to go this far.
> Enabling
> people to build their own content negotiation replacement is one
> thing, explicitly coding one into the framework is another - i.e. I
> think we should enable common workarounds, but not encourage them.
Such "tunnel" service could be turned off by default to not "encourage"
relying on it.
Best regards,
Jerome