Hi, from a specification point of view I have the following approach:
a) The specification links to the HTTP 1.1 specification and demands that federating servers adhere to this HTTP standard. This implies that servers CAN use pipelining, connection keep-alive and zipping. b) The specification will (i.e. does not yet) read: Implementations of the protocol SHOULD use connection keep-alive. This way every plain HTTP 1.1 implementation is compatible (this is what "a" says). Second, we hint that for efficiency at least connection-keep-alive should be implemented (that is "b"), but in the worst case we could live without. Zipping and pipelining is not implemented everywhere, thus I do not want to enforce them. I believe that pipelining will be even more important than zipping (believe = did not measure it) most of the time. The reason is that ProtoBufs containing signatures and hashes do not lend themselves so well to zipping. If, however, a server requests a large wavelet history, zipping might be extremely helpful Well, the essence is: If both servers support it they can negotiate and use it as John already pointed out. Greetings Torben 2010/11/16 Michael MacFadden <[email protected]> > 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- --------------------------- Prof. Torben Weis Universitaet Duisburg-Essen [email protected] -- 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.
