Michael, In working on the HTTP federation, we decided to use Jetty's HTTPClient [1] and ContentExchange [2] classes. This allows us to make asynchronous HTTP requests to a server and define an "onResponseComplete()" method that handles the HTTP response. From my initial reading of the documentation, it looks like it pools connections to a server and allows for reuse. I'll do a little more looking around to verify. Anyone else know for sure?
As for gzip, it's something we definitely discussed. While the protocol is pretty tightly-packed, for bandwidth constrained environments it should be an option to compress, like you mentioned. What we might need to do is, during the discovery, have the server send the header "Accept-Encoding: gzip". Then, the client would be able to send gzip'd content via the header "Content-Encoding: gzip". Does anyone know if we can leverage any Jetty features to help out with this? -John [1] - http://download.eclipse.org/jetty/7.1.6.v20100715/apidocs/org/eclipse/jetty/client/HttpClient.html [2] - http://download.eclipse.org/jetty/7.1.6.v20100715/apidocs/org/eclipse/jetty/client/ContentExchange.html On Tue, Nov 16, 2010 at 12:25 PM, Michael MacFadden < [email protected]> wrote: > 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. > > -- 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.
