-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Drew, >> Should WebSocket transport allow to use different opcodes (i.e. >> binary vs. UTF messages)? > > I think the question we face here is a fundamental challenge to > the original design of transports: a nanomsg transport is a dumb > pipe over which any kind of content can go over any type of > protocol. However WS as specified by W3C doesn’t fit well into > nanomsg’s mold; it’s a thing that wants to be content-aware. > > If there is a real use case and someone willing to do the work then > I certainly think the idea of content-aware transports should be > explored. I’ve long been a critic of the protocol/transport model > as too simplistic. > > However in this case I think it is difficult to arrive at a simple > proposal because with the scalability protocols sitting between > the application and WS transport it’s not clear to me how a > restriction on (for example) UTF-8 content arriving through an > arbitrary scalability protocol could even be enforced. So I’d like > to hear more about the use case for using WS opcodes in nanomsg. My position on this that the transport should just be a dumb pipe, all messages being binary. After all, nanomsg API sends & receives binary blobs. Jack's opinion, I think, differs. >> 2) Should SP type IDs be in text format (as is the case now) or >> should they just be numbers (as in all other transports)? > > I would prefer numbers, since reserving a protocol number seems > hard enough ;-) Reserving both numbers and names is somewhat redundant, but, OTOH, not prohibitively so. So, if there's a good reason to do that, we should. However, so far the only reason I see is that WebSocket protocol requires text in this field and using strings like "SP-17" is a bit ugly. Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJUZ14YAAoJENTpVjxCNN9YOMoH/3Q5ASO5MMndfS797n0zVEr2 vl7V6EkNk2vq/POnceqM3k+SDWBCAhflTyg72iA/dTWzzV6712JjeCXR7EX7Gm91 gxc/ZcJ5xzsugNQClku6G4VjdjNv6pYn+kGF+XePWipk0Yq8VvmrtnLUUgQKmdFa /KSreaXJR6nXT+pQVcRyWryjagJ+xuL1+39y3UGcoULwhVSXvFnte00ZgPjBUA6X k75zTYifHgF+nhTeeTRvQHWrs8OxbUFPabUg4ZGsiaIrPNViMqkf2YYK38ju2p+y BOAIQMjdnd1ft/VhUF5v7NmZDMB6WVjTJ0LDgeFISJWCs88hBWPecU96MZQcArA= =H+es -----END PGP SIGNATURE-----