Justin Deoliveira escribió:
> Andrea Aime wrote:
>   
>> Justin Deoliveira ha scritto:
>>     
>>> Sounds like a good idea. One question though. Do we plan to support 
>>> this via POST requests? Adding extensions via GET is easy enough but 
>>> once you start doing it with xml you have to worry about schemas and 
>>> what not... it can get messy.
>>>       
>> Oh yeah, I was not planning to add explicit changes to the XML POST.
>> If the user wants to use this feature, they can post to
>> ows?format_options=shapefileEncoding:ISO-8859-1
>>
>> and the dispatcher will take care of that.
>>     
> Oh yeah, go dispatcher go! :)
>   
>> Mumble... another option that might work is to include the parameter
>> in the output format, but there would be no way to advertise it:
>> outputFormat=SHAPE-ZIP;encoding=ISO-8859-1
>>
>> That would work cleanly with POST as well thought.
>>
>> Cheers
>> Andrea
>>
>> PS: the point of advertising the param is quite moot imho, what
>> software can actually use advertised params?
>> We're talking of an extension to a non standard format, no
>> automatic software can do anything intelligently with it
>> anyways afaik.
>>     
> I tend to agree. I mean there is barely software that does wfs properly, 
> let alone taking advantage of these options. Declaring stuff like this 
> seems like splitting hairs until there is some sort of agreement among 
> clients.
>   
Tend to agree too, but then I wonder if at least we can advertise them 
as different outputformat entries, like
SHAPE-ZIP
SHAPE-ZIP;encoding=UTF-16
SHAPE-ZIP;encoding=ISO-8859-1
SHAPE-ZIP;encoding=....
not that we need an entry for each and every JVM supported charset... we 
could just add the most used ones in the spring applicationContext if 
the shape outputformat bean supports a charset parameter... the backside 
is with formatOptions you get all the available encodings, this way you 
limit them to a bunch...

just a thought though

Gabriel
>
>
>   


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to