[Libwebsockets] Q on protocol names
mail17 at mah.priv.at
Mon Aug 11 04:28:13 CEST 2014
Am 11.08.2014 um 03:35 schrieb Andy Green <andy at warmcat.com>:
>>> Because protocols themselves mandate specific code support that
>> either exists in the server / client or not, handling them as static
>> definitions seems more natural...
>> that's generally an ok assumption. The way I deal with the
>> variants/version issue is: I parse the protocol names list in
>> FILTER_PROTOCOL_CONNECTION, decide which one to use, record that in my
>> private session structure, and let the library know of that by calling
>> libwebsocket_set_protocol(wsi,name, <opt proto if not default>).
> How about just add an int to the protocols struct representing any information about that version of the protocol (capability bitfield, version ordinal etc) and let the existing code and static protocol structs do everything. It's extensible to a large number of protocols / versions and does not require user code to parse anything, nor add strings to protocol matching in the rest of the code.
so the new protocols field is filled in statically/compile time and the callback inspects it to decide what to do?
if so - well 'simple' beats 'more code' any day, I think that covers it for me. I guess karlp's problem too.
> Is there any feature that your scheme gives us we actually miss out on if we just do that? Yes you'd have to enumerate the protocol versions you support, but how many can we be talking realistically? Ten or twenty as a one-off scan at connection upgrade time sounds OK.
> BTW you mentioned the code spun when you gave a NULL name. I pushed a patch to fix that.
I was a bit unclear what the NULL proto name was suggested to mean - match any proto?
More information about the Libwebsockets