* Hugo Duncan [2011-11-07 13:56] writes:
This makes the messages less easy to inspect, and less easy to write integration tests for.
Only marginally. Shifting 3 bytes together is not exactly rocket since.
It isn't rocket science, but does remove the possibility of visual verification, and of being able to send messages via scripting or a simple console. HTTP, SIP, SMTP, and STOMP are all good examples of protocols with text headers, and I think appropriate, if one looks at swank as a sort of control protocol.
If HTTP is so great then why are WebSockets specified as a binary protocol?
What is the gain from changing to a binary header? As far as I can see it is just saving a few bytes.
Aesthetics?
Normalising on utf-8 and counting bytes sounds like it would solve the original issue without changing to a binary encoding of the message length.
Right. It would not be backward compatible, tho.
It seems to be worth solving encoding issues, so something has to give.
Given this is a breaking change, I also see the desire to introduce an extension mechanism at the same time. I would argue a text based header/value extension would be more appropriate.
A fixed sized header is a clear efficiency win. It's also easier to implement.
At the end of the day, I realise the balance between the respective merits of binary and text headers is somewhat subjective.
Yes, it's also rather academic as there are only 2 or 3 people that need to debug this.
Helmut