Re: [hybi] [permessage-deflate] Renaming s2c_ and c2s_ prefix to server_ and client_

Mostly neutral here with a slight preference for s2c/c2s vs server_/client_ for the following reason:

server_no_context_takeover

If I am a server receiving a message does this parameter apply to me? well it says server.. but in fact it doesn't.
If I am a client receiving a message does this parameter apply to me? well it says server.. but in fact it does.

s2c_no_context_takeover

If I am a server receiving a message does this parameter apply to me? In the prefix, server is not in the receiving position, does not apply.
If I am a client receiving a message does this parameter apply to me? In the prefix, client is in the receiving position, does apply.

The original relies on the spec to encode the fact that the s and c in s2c are "server" and "client". The proposal relies on the spec to encode the fact that server_ implies server to client. I found the explicit mention of both ends in the parameter helpful for quickly working out whether a particular parameter applied to a particular piece of code without referencing the spec.

Whether that outweighs the initial cryptic-ness of "s2c/c2s" I don't have a strong opinion on. I'd prefer server_no_context_takeover to server_to_client_no_context_takeover. In the grand scheme of things the difference is minor and I'll be fine with updating WebSocket++ either way.

Peter

On Oct 9, 2013, at 3:06 , Takeshi Yoshino <tyoshino@google.com> wrote:

> (Splitting into an independent thread)
> 
> Joakim suggested that we should rename them.
> http://www.ietf.org/mail-archive/web/hybi/current/msg10201.html
>  > Since all websocket communications are initiated by client to server
>  > these should just be s/s2c_/server_/g and s/c2s_/client_/g
> 
> Initially, I chose these prefixes to make it easy to understand that they're attributes for each direction by including source and destination explicitly. But server_ and client_ are not so confusing, too. As these parameters are request about the peer's output, everyone should understand X_no_context_takeover and X_max_window_bits as parameters instructing compressor of X.
> 
> If we do this, we should do this right now. I don't have strong opinion about this change. If there's no objection, I'll take it.
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi