All, Great work on the transport, I think it is great that we are looking at alternatives. One of the original concerns I had with XMPP was it's verbosity and therefore its less than optimal bandwidth utilization. The proposed HTTP Transport looks much more compact in that regard. I do have a question regarding how HTTP will be used efficiently in this regard.
Typically a RESTful HTTP model will use independent http connection for each request. Since HTTP is a TCP type protocol, most implementations wind up opening up a new TCP connection per HTTP request. TCP connections are optimized for long live connections, they have a "slow start" behavior where there is significant overhead to set up the connection, but then operates with better performance once it is set up, persisted and used for longer term data transfer. This was one of the main upgrades to the HTTP protocol between HTTP 1.0 and HTTP 1.1. HTTP 1.1 supports persistent connections and request pipelining. The concept being that most web requests are short, and you get much better performance if you keep the connection open for subsequent requests. It seems likely that wave requests will also be small, but frequent. It is easy to see that when people are collaborating on a live wave, the deltas flowing between federated servers will be small and frequent. I think it would be worth while to attempt to use persistent HTTP connections between servers that are federating to accomplish this rather than a new connection for each message. XMPP for better or worse did use long lived TCP connections. Maybe this is implied already for the proposed HTTP transport, but I wanted to put it out there. Also is there a possibility of standardizing around some sort of compression scheme like gzip that is supported by HTTP? Is this overkill, if the protocol is sufficiently packed already? HTTP already seems to have a mechanism to see negotiate if compression is supported on both ends, so I this could be optional, but we could make it mandatory if we wanted. Again I am thinking about highly bandwidth constrained environment. Thanks. comment on the proposed HTTP Transport. On Nov 15, 1:56 pm, Torben Weis <[email protected]> wrote: > Hi, > > one outcome of the great wave summit in SF is a draft specification for > HTTP-based federation. > Find it at: > > http://www.waveprotocol.org/protocol/design-proposals/http-based-fede... > > Currently, some open source wavers are implementing the protocol in WiaB. I > am working on a second implementation for lightwave. > If you have any comments regarding the protocol, we can discuss it here. > Currently there is no formal procedure of how to maintain this > specification. > Until this is sorted out, I am acting as the editor for the spec. > > Greetings > 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.
