On Thu, May 13, 2010 at 4:09 PM, J.D. Zamfirescu <[email protected]> wrote: > The rationale for using indexes instead of names is that (1) the JSON > format is just a protobuffer serialization, and (2) protobuffers > specify that index numbers, not key names, are constant.
Let's start from basic principles: do you expect that this client-server protocol will eventually be a standard? If the answer is Yes =========== We need to take a step back and review the nature of 'standard'. The point of a standard is that it is an unchanging document that describes how to build something, either a document or a protocol, in enough detail, and relying only on other standards, that anyone can come along and implement the standard without talking to you, creator of said standard. There are two real important bits to take from that, the first being that the standard, once completed, doesn't change. Yes, there may be new versions of said standard (HTML5 vs HTML 4.01), but the old standard never changes. [And this client-server protocol does have a version number, right?] The second is that standards are built on top of other standards. That solid, unchanging foundation of specifications is what makes progress possible. In that light I would like to point out that if you want to make the wire protocol for the client-server protocol based on a serialization of protocol buffers then: The protocol buffer definition will go into the spec and will not change. Ever. That leaves two other issues: 1. There is no standard for Protocol Buffers. 2. There is no standard for the serialization of Protocol Buffers into JSON. But both of those obstacles can be overcome with sufficient effort. If the answer is No =========== Then why bother? Leave the published code as an example of a client-server protocol and make it as simple and readable as possible to guide real client-server implementers and it won't matter if the protocol buffer definition changes over time. Thanks, -joe > > I agree that the key names are more readable, and would prefer to use > them myself, but consensus here seems to be that using key names in > protobuffer-based messages is Unwise™. > > (In other words: if you feel very strongly about this, make more noise. > <grin>) > > J.D. > > > On Thu, May 13, 2010 at 8:24 AM, antwatkins <[email protected]> wrote: >> I like the update to make the naming convention consistent, however, I >> am not sure about using index values instead of key names. I >> understand that it will make the messages smaller and parsing slightly >> faster, but I think this is counter to one of the stated goals of this >> push which is >> >> "Hopefully this new transport will be easier to work with for client >> authors working in non-Java languages." >> >> From a high-level view I think developers comfortable binding this >> closely to a Protobuf object may be better suited to just using the >> client/server protocol based on ProtoBufs. I like the idea of a >> message protocol that is easy to understand by just looking at the >> format and I think it will relay better to external developers not as >> well versed with native Google tools. >> >> R, >> >> Anthony >> >> On May 12, 10:02 pm, Joseph Gentle <[email protected]> wrote: >>> Right - so change it to something like this then? >>> >>> // In waveclient-rpc.proto >>> message WebSocketRPCMessage { >>> required uint32 version = 1; >>> required uint64 sequence_number = 2; >>> required string message_type = 3; // We wouldn't actually need this >>> anymore... >>> >>> // At least one of these must be set >>> optional ProtocolOpenRequest open_request = 10; >>> optional ProtocolWaveletUpdate wavelet_update = 11; >>> optional ProtocolSubmitRequest submit_request = 12; >>> optional ProtocolSubmitResponse submit_response = 13; >>> // .... more added later? >>> >>> } >>> >>> ... And pretty printed, the JSON message looks like this: >>> { >>> "1":0, >>> "2":1, >>> "3":"webserver.ProtocolOpenRequest", >>> "10": >>> { >>> "1":"[email protected]", >>> "2":indexwave!indexwave", >>> "3":[""] >>> } >>> >>> } >>> >>> Doing that trick with a series of optional message types can make >>> parsing faster than if you send the type as another string. (You can >>> be sure you'll always have parsed the key before the message, so you >>> know the message's type. That lets you read it directly without using >>> intermediate representations.) >>> >>> -Joseph >>> >>> >>> >>> >>> >>> On Thu, May 13, 2010 at 9:28 AM, J.D. Zamfirescu <[email protected]> wrote: >>> > Hey! >>> >>> > That would be great. In fact, what we want to do is further use the >>> > protobuf indexes instead of the key names. If you can pull this off on >>> > the client and server that would also be excellent. >>> >>> > And, yes, a version number bump would be great, and we are working on >>> > client-side websocket stuff but we need to do this anyway. :) >>> >>> > Thanks! >>> >>> > J.D. >>> >>> > On Wed, May 12, 2010 at 6:06 PM, Joseph Gentle <[email protected]> wrote: >>> >> There's a couple changes I'd like to make to the fedone websocket >>> >> message protocol: >>> >> - The JSON currently has inconsistent naming conventions >>> >> (sequenceNumber vs participant_id - see below) >>> >> - WebSocketChannel.MessageWrapper should embed the message as a JSON >>> >> object, not a JSON object encoded inside a string. (The latter is >>> >> sloppy to send and use). >>> >>> >> Currently messages look like this: >>> >> { >>> >> "version":0, >>> >> "sequenceNumber":1, >>> >> "messageType":"waveserver.ProtocolOpenRequest", >>> >> "messageJson": "{ >>> >> \"participant_id\": \"[email protected]\",\"wave_id\": >>> >> \"indexwave!indexwave\",\"wavelet_id_prefix\": [\"\"]}" >>> >> } >>> >>> >> ... I'd like to change it to this: >>> >> { >>> >> "version":0, >>> >> "sequence_number":1, >>> >> "message_type":"webserver.ProtocolOpenRequest", >>> >> "message": >>> >> { >>> >> "participant_id":"[email protected]", >>> >> "wave_id":indexwave!indexwave", >>> >> "wavelet_id_prefix":[""] >>> >> } >>> >> } >>> >>> >> Questions: >>> >> - Should I just write & submit a patch? Who should I send it to? >>> >> - Should I bump the protocol version number for a change like this? >>> >> - How many people are effected by changes like this? (Are many people >>> >> working on client code using websockets?) >>> >>> >> Cheers >>> >> Joseph >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Wave Protocol" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group >>> athttp://groups.google.com/group/wave-protocol?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Wave Protocol" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/wave-protocol?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
