On 1/21/13 4:24 AM, Mark Thomas wrote:
> On 19/01/2013 16:39, Justin Lee wrote:
>> On Fri, Jan 18, 2013 at 8:23 PM, Danny Coward<danny.coward_at_oracle.com>wrote:
>>> * Extension parameter ordering
>>> http://java.net/jira/browse/WEBSOCKET_SPEC-105
>>>
>>> Currently the API models extension parameters as Map<String, String>, yet
>>> the parameters have an order in the http headers. While this order doesn't
>>> have a meaning in the websocket protocol specification, both the MUX and
>>> Compression extensions attach semantic meaning to specific parameters, so
>>> it is perfectly possible that some new extension might attach semantic
>>> meaning to their order. So, I think our API needs to preserve them. I
>>> suggest we model extension parameters as List<Parameter> where Parameter is
>>> a member type of Extension, and contains the parameter name and value as
>>> Strings.
>>>
>>>
>> I don't think header ordering matters anywhere in any common protocols. I
>> don't think we should bend over backwards making this a requirement outside
>> of something forcing us to. I'd be really, really surprised if any
>> extensions make it out of specification with that requirement. Even HTTP
>> only specifies the first 2ish headings and that's merely to aid in protocol
>> identification. I'm a -1 on this one.
> Since HTTP does define an order for parameter values within an HTTP
> header then I think it is reasonable that our API retains that order
> unless there is a good reason for not doing so.
Yes I agree with Mark on this one. Ordering of the extensions themselves
is semantically meaningful within the websocket spec, and while the
ordering of a particular extensions parameters don't seem to be being
used by any of the existing extensions, we just don't know if they will
in the future.
I'd rather we not be the spec that gets in the way of that !
- Danny
> Mark
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation