|Re: [jgit-dev] Gitblit, JGit, and SPDY|
On Thu, Mar 29, 2012 at 10:20, <james.moger@xxxxxxxxxxx> wrote:Not a whole lot. I'm not an expert on SPDY, but a well behaving
> Since I read Jetty's announcement of a shipping, stable(?) SPDY
> connector with automatic HTTP fallback I've been thinking of updating
> Gitblit's Jetty dependency.
> Not that I am complaining about SmartHTTP, but I'm wondering if Jetty's
> SPDY implementation (there is a stand-alone client library) brings
> anything to the table that JGit could take advantage of?
anonymous SmartHTTP clone or fetch should be 2 HTTP requests, reusing
the same HTTP connection by way of HTTP keep-alive. SPDY might be able
to shrink the headers of that second request by reusing information
like the User-Agent header from the first request. But that isn't much
data to save.
A bad case for SmartHTTP is one that requires authentication and a
number of negotiation rounds to find the common ancestors. This is a
bunch of sequential round trips, so the SPDY compressed headers may
save some transfer time. But they should all be running on a single
keep-alive managed connection. Since the requests are all sequential,
many of the advantages of SPDY are not useful here. Being able to run
multiple resource requests in parallel on the same connection, or push
resources in advance of the client asking for them can help web
browsers show HTML faster, but doesn't really help SmartHTTP.
Now WebSockets might be useful since it makes a stateful bidirectional
channel available, as Git might be able to run the normal multi_ack
protocol on it. Unfortunately WebSockits is also a pretty complex
Back to the top