Hi Alex,
I agree, the current map-based implementation is limiting. We need to change
it to a more flexible structure, ideally without impacting too much the
current API. I've reopened the issue:
http://restlet.tigris.org/issues/show_bug.cgi?id=393
Best regards,
Jerome
2007/12/10, Alex Milowski <[EMAIL PROTECTED]>:
>
> On 12/9/07, Jerome Louvel <[EMAIL PROTECTED]> wrote:
> >
> > Alex,
> >
> > > Sufficient to fix my current problem but the fact that it doesn't know
> > > by default what extension to given application/xml.
> >
> > The problem is that ".xml" already maps to "text/xml"...
>
> I would expect that you'd have a default media type for when you
> as "what media type goes with this extension" but that multiple
> media types would be allowed to map to the same extension.
>
> If you look at RFC 3023 [1] you'll see that both the text/xml and
> application/xml media types have the .xml extension. As such, I would
> expect to get the same answer of the ".xml" extension for both media
> types.
>
> I don't think the current system supports this.
>
> As I understand it, the code:
>
> myApp.getMetadataService().addExtension("xml", MediaType.APPLICATION_XML
> );
>
> will just shift the problem from the application/xml to the text/xml
> media type in
> that I now won't get an extension returned for text/xml.
>
> [1] http://www.rfc-editor.org/rfc/rfc3023.txt
>
> --Alex Milowski
>
