> > > Actually, protobufs are used in the federation protocol and thus must > be standardized, so that's not really an option. >
Hmmm, one obstacle less for introducing numbers :-) > > Now on the efficiency front I don't disagree, I just believe the > efficiency gains are minimal and don't outweigh the benefits > of a readable protocol. If efficiency really is an overarching concern > then let's transport protocol buffers over websockets. > In the end it boils down to a question that cannot be answered ultimately. While we can measure the bandwidth wasted by symbolic names, we cannot exactly define how much "easier" the symbols are. Even if we could: How should we compare these values? So in the end it is a question of believe and perspective. > > > 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. > > The odd thing is that you can use your points to argue that > we shouldn't be using XMPP for Federation. > Now that you mention it .... :-) It is not "odd" at all. Let me make a slightly exaggerated statement: Using XMPP has no technical reasons or merits, hinders wide-spread wave adoption and wastes bandwidth of course, but bandwidth is the smallest problem by the way. I do not want to offend anybody. It is just a thought experiment. However, here are some arguments to support the claim. A) XMPP has no technical reasons and merits A.1) Wave does not USE XMPP, wave simple tunnels through XMPP The way wave works currently is that it sends message from host A to B as unicast messages. These messages are only tunneled via XMPP. It is quite hilarious that the spec refers to XEP 60 (publish/subscribe), because it uses pub/sub exactly nowhere. Of course, it uses some of the tag names specified in XEP 60, but that's it. There is nothing in the protocol where a bunch of hosts subscribe to a topic and another host publishes this topic without knowing the subscribers, leading to a multicast of this message to its subscribers (because that is what pub/sub does). A.2) There are little re-use benefits of existing software The power of XMPP servers is not really used because wave simply tunnels through. Existing XMPP clients cannot make any use of wave data because inside the XMPP XML-messages we find some totally screwed combination of base64 and protobuf which normal XMPP clients cannot understand. Thus, you cannot argue that some great software can be reused because of XMPP. In contrast, a rather complex XMPP server must be reused with very little gain. B) Wave hinders wide-spread adoption B.1) XMPP is not as wide-spread as many XMPP-fans think. I can only judge by my experience with several universities and companies in Europe where I had the pleasure to work. None of them had any XMPP infrastructure. Of course, Google has for GTalk, but I guess that's about it. B.2) XMPP certificates suck Until this day I have NO WORKING CERTIFICATE! which is a shame considering that I re-implemented almost every bit of wave. My servers belong to the university which issues certificates: for web, mail, you name it, but not for XMPP. Heck, they do not even know what that is. Don't point me to startssl.com & friends. When working for a large institution you cannot simply do what you want. IT departments want to have it their way. And XMPP is not their way. B.3) DNS SRV entries suck Ask an average computer science student how to resolve an XMPP server via DNS. I do this a lot in oral examns. You would be terrified by the results. Ask an engineer in a large institution how difficult it is to get the DNS entries done and all required ports open ... It's all easy for your own home-build server. But in large companies it is difficult to introduce wave through the back-door. A lot of official blessing is required to get the technology up and working, even for a test installation. C) Using XMPP the-wave-way wastes bandwidth and CPU time. I spare you my thoughts about XML in general. I assume you could make a good guess :-) When decoding a wave federation message one must parse as follows: a) Parse XML b) Navigate through the DOM and find some strings. c) Base-64 decode these strings d) Use protobuf on the binary from the base-64 decoding. That's insanely complex and inefficient. How does that compare to "symbols" versus "numbers"? Well, after writing it down I feel a lot better :-) although I do not expect it to change anything. I want to conclude with an alternative approach to make this mail a bit less destructive: APPROACH: Use web technology that everybody and his brother understands. Run the federation protocol via HTTPS with keep-alive and optional pipelining. Encode the messages as protobuf binaries. By saving on the XML tags and base64 madness, we can save more bandwidth than we waste on HTTP headers. And remember that we have currently no attachment support. In the end we will do this by HTTP anyway. Hide the wave server behind a web server and connect via FastCGI (that is what my server is doing anyway). Admins know how to secure a web server and everybody has one. Use the web server certificate for signing deltas. Everybody has them or at least they are more easy to obtain. Run the client/server protocol via number-encoded JSON and HTTP/HTTPS. The wave server can do all the login stuff and forward JSON to the wave server via FastCGI (that is what my server is doing, but I assume you have guessed that already :-) What's the advantage? I believe that this is much easier to setup since it involves only standard components and protocols which are understood and supported almost everywhere (HTTPS, web certificates, FastCGI). In the near future websockets might be added to the mix. Thanks for listening Torben -- 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.
