Torben, Great, I think adding the language just as you mentioned (with appropriate protocol spruce up) is right on the money.
John, I know that you can implement Gzip as a servlet filter pretty easily. Jetty supports the servlet api, so we should be able to leverage filters. The nice thing about this approach is that you don't actually have to change the servlet code that already exists, and the common filter approach checks to make sure both sides understand how to deal with gzip before applying the logic. When doing the implementation, we can take a look at this. ~Michael On Nov 16, 3:19 pm, Torben Weis <[email protected]> wrote: > 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%2bunsubscr...@goog > > legroups.com> > > . > > 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.
