Torben, I think you make many valid points and as a user of QWave I do not take your opinion on client-server communication lightly. However, I agree with Joe that key names are more appropriate than indexes for the specification.
I think the key goal of the federation effort is adoption. Using key names is easier to read, easier to implement, and more precise as it presents a higher level of detail. Using numbers requires more documentation and more reading on the part of potential adopters. The more developers have to read and make associations of encodings the less that will adopt the technology. No, using key names is not more efficient. To that I say that client authors will necessarily make their own optimizations to the client- server protocol. Desktop developers, web developers, and mobile app developers will all have their own requirements and are free to make whatever changes to their client-server protocol just as you did. Federation will still work between wave servers. The console based client is intended to just illustrate how a client may communicate with the server. It is not optimized or intended for production. I think using key names instead of indexes provides an easy to understand implementation for client authors that they can easily update for their own means. So in this case I think adoption trumps performance. When I consider that argument, I think about Google's decision to use XMPP for the federation standard. No one will argue that XMPP is the lightest or most efficient protocol. I recall a post from Daniel Berlin of Google on why they choose XMPP (http://groups.google.com/group/wave-protocol/ browse_thread/thread/1a6a590a411b9704/c0e2e561ce0a8794?lnk=gst&q=xmpp +large+protobuf#c0e2e561ce0a8794): "We actually plan on [an extension of federation protocol to use protocol buffers], but honestly, one of the reason we chose an XMPP extension to start was because uptake by larger providers is going to be dependent on being able to integrate into their infrastructure. Most have XMPP servers (or could, etc), but trying to get them to use all unfamiliar google technology was not a good story. :) " I think the masses are better served by using key names and indexes should be reserved for individual client authors that choose to make that optimization. Client authors do not have to be concerned with any other developer/user of FedOne understanding their implementation (only their internal shop), but Google through this federation effort does have that concern. Just my take. v/r, Anthony On May 14, 7:32 am, Torben Weis <[email protected]> wrote: > Joe, > > I tend to disagree. Your argument is basically that a standalone standard > should not depend on protobufs which are not standard. > I agree. > > However, if the standard says you should send > { foo: <string>, bar : <number> } > to the client you can as well specify that "foo" and "bar" are symbols which > have to be replaced by "1" and "2" in the protocol. > Thus, in the standard document you first use the symbol names to foster > understanding and then you provide an encoding table which maps symbol names > to numbers. > > Even ASN.1 does the same. They talk about tags, which are names. And then > they tell how to encode these tags in bits. > > Furthermore, a communication protocol should not be designed to be readable. > It should be designed to be precise, easy to implement, efficient and > platform neutral. > > Of course you may argue that a HTTP header has names for the header-entries, > such as Content-Length instead of numbers and we survived this bandwidth > abuse. True, but in Wave we are transmitting messages on a key-stroke level. > There is a reason why you use WebSockets instead of good-old HTTP. > > BTW an implementation hint: My C++ wave server implementation uses the > number-based-JSON since its existence. I have written two small tools (which > are in the QWaveClient SVN). They link Google's protobuflib to read a proto > file and generate JSON serialization code in C++ and JavaScript. The > compiler is in /tools/protojs. In /tools/libprotojs is a C++ > JSON-parser/encoder. > It is not too difficult to do the same for other languages. (With this > paragraph I just want to support my argument that number-based JSON is still > easy to implement). > > Cheers > Torben > > 2010/5/14 Joe Gregorio <[email protected]> > > > > > 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]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > >>> 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]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > >> 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]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > > For more > > ... > > read more » -- 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.
