Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> I see two possible solutions:
>>
>> 1) we add the method you are proposing. However I see a possible problem
>> with this (i might be understanding). The problem is that isn't there
>> loss of information in the cases there the output format actually does
>> multiple different formats, rather just provide synonims. For instance
>> with geotiff and geotiff8, if you map this two a single string how do
>> you know how to do the reverse mapping.
>>
>> Or... are you prosing that getOutputFormat return a list... and based on
>> the flag that list might contain synonyms or not.
>
> Yep, this one. Returning a list, without synomyms if the boolean
> parameter is up.
>
>> 2) the second way to solve this would be to come up with some sort of
>> mapping extension point, that could map mime types or output format
>> names to human readable titles. Something like:
>>
>> class OutputFormatTitle {
>>
>> String getTitle( String outputFormat );
>> }
>>
>> With this extension point the ui could walk through and build up the
>> list of titles (factoring out synonyms since synonyms would map to the
>> same title string).
>>
>> While I think the first would be easier to implement it kind of seems a
>> bit hackish... the second I think is a bit cleaner and means we don't
>> have to muck up any of the existing output format code.
>
> The second is basically there already, the mapping function is
> looking up the title on the i18n subsystem using the mime as
> a key (works, you have to escape spaces and equals in the key)
> but I did not like it much. To me having the synonyms in the
> output formats seemed the hack instead: the capabilities
> are sending out this duplicated blob of formats as well,
> and a smart(ish) client can present that very list to a user.
> Here is what comes out of the WMS caps (on 1.7.3):
I would prefer a shorter list too, but at the time aliases were needed
because there were already a lot of code using them, but they weren't
advertised in the capabilities. That is, everybody wanted to use
"openlayers" or "atom" in the requests, but those were just not in the
capabilities, so it was magic.
Moreover, the ones without the "+" where required for those sending a
request from a web browser that does not escape the spaces in the URL.
Hence the aliases, to stop magic.
This issue is somewhat related <http://jira.codehaus.org/browse/GEOS-2124>
some things like image/geotiff, image/geotiff8, image/png, image/png8
etc should imho be better advertised as a parametrized MIME type, eg,
image/png;color-depth=8 or image/tiff;geotiff=true
comments?
>
> <Format>image/png</Format>
> <Format>application/atom xml</Format>
> <Format>application/atom+xml</Format>
> <Format>application/openlayers</Format>
> <Format>application/pdf</Format>
> <Format>application/rss xml</Format>
> <Format>application/rss+xml</Format>
> <Format>application/vnd.google-earth.kml</Format>
> <Format>application/vnd.google-earth.kml xml</Format>
> <Format>application/vnd.google-earth.kml+xml</Format>
> <Format>application/vnd.google-earth.kmz</Format>
> <Format>application/vnd.google-earth.kmz xml</Format>
> <Format>application/vnd.google-earth.kmz+xml</Format>
> <Format>atom</Format>
> <Format>image/geotiff</Format>
> <Format>image/geotiff8</Format>
> <Format>image/gif</Format>
> <Format>image/jpeg</Format>
> <Format>image/png8</Format>
> <Format>image/svg</Format>
> <Format>image/svg xml</Format>
> <Format>image/svg+xml</Format>
> <Format>image/tiff</Format>
> <Format>image/tiff8</Format>
> <Format>kml</Format>
> <Format>kmz</Format>
> <Format>openlayers</Format>
> <Format>rss</Format>
>
> As you can see, rss is expressed 3 times, kml a whopping 6
> times, and so on.
>
> Cheers
> Andrea
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
