It seems like there's three different 'optimal' protocols: 1) For readability, json with descriptive keys is a winner. This requires that the protobuf key names never change.
2) For a web client, you can't use binary. If you want to optimise for size & speed, using protobufs sent via json with numbers for keys should work great. This requires that protobuf field IDs never change, which is easier to arrange. 3) For a desktop client, it makes the most sense to use a binary protobuf format. (Less work, better tools, most efficient.) I don't know how many client-server protocol standards we want. Probably just the one. If there's only one protocol, it must work with web apps, so (3) is out. That makes the choice between: - Readability vs - Size (~25%-50% at a guess) - Ability to change protobuf field names I vote for sacrificing readability. Its a bit more work for implementers, but not much. The size improvement is nontrivial and it is quite nice being able to rename fields[1]. -Joseph [1] I've seen people do stuff like have a field: optional int attribute_munge = 10; ... which was later renamed to: optional int __OBSOLETE_attribute_munge = 10; // do not use - use attribute_funge instead. Then good protocol debugging tools update to reflect the change. It makes for good workflow. -- 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.
