--On November 24, 2005 3:05:07 AM -0800 Greg Stein <gstein@lyra.org> wrote:
> In terms of writing code, while I haven't had time personally, I can
> make it possible for others :-) I have an intern starting in January
> to work on serf and svn integration. I'll make sure he knows that he
> can talk about it whenever he's up for it.
*raises hand*
As some of you may already know, Google has hired me to work on Subversion
with my main goal of integrating serf with Subversion.
Google and I (since, well, I accepted!) both view this as an excellent
opportunity to finally realize the ideas Greg and I have had for a long time
about Subversion and serf. We can finally prove that DAV on the client-side
doesn't *have* to be complicated and slow. We do hope that we'll be able to
improve Subversion client's WebDAV performance substantially.
For those that aren't aware, Serf is an HTTP client library that is loosely
modeled after the httpd architecture. Serf's code base lives at:
<http://svn.webdav.org/repos/projects/serf/>
Serf is an asynchronous library that does pipelining, deflate, SSL, chunking,
etc. today built on top of APR. As Greg mentioned in a later post, there is
some 'friendly' stuff that neon does that serf doesn't do yet - so part of the
enhancements to serf will be to improve on the accouterments that serf offers.
We believe that serf can offer a better HTTP client platform for us than neon
does because without pipelining, we're just too slow. As I said in my earlier
posts, using custom methods also kills any potential to placing a cache in the
mix. Therefore, I have a real strong dislike for custom REPORT methods and
want to return to a GETy model on the client-side. (REPORT goes against
everything that HTTP/REST is about!)
Due to obligations that I need to complete before I head to Google, I haven't
sat down in detail and sketched out how it will all work out yet. I do know
that I intend to create a new ra_serf layer (for lack of a better name) that
will aim to replace ra_dav with Neon. The code-bases of neon and serf are too
different to share the same ra layer on the client-side. (We'd likely make
ra_serf/ra_dav a configure-time option - you'll get one or the other.) I also
have some ideas for some other nifty features that we'll be able to add with
serf that we can't do with neon as well.
With Google's blessing, I plan to do all of the Subversion integration work
here on dev@svn and have the code reside in a branch until we're ready to
discussing merging it to trunk. Of course, that'll mean that I will hammer
out a design proposal before we create the branch here. In DannyB fashion, I
may just throw up a first-cut implementation here to guide the discussion. =)
My work will be primarily focused on the integration of Subversion and serf,
but there may be things along the way that I'll also touch on. Since I'm also
knowledgeable about httpd and caching, I may also make improvements to
mod_dav_svn as necessary. But, that's not my real focus.
I'm excited about this opportunity that Google is giving me to put my time
where my mouth is. So, while embarking on a rewrite of ra_dav to go to a
strict REPORT model is cute, I'm going to have the cycles to put a big
bulls-eye on that model and do my best to shoot it down. =)
To give an idea about the estimated timeline, I'll be starting at Google in
mid-to-late January and will be there until April. I'll keep an eye on
dev@svn until then, but I'll be focused on other things until I officially
start. For those that care and understand the ins-and-outs of academia, I'm
advancing to candidacy for my PhD in mid-January. Needless to say, I'm
*really* swamped until I pass that hurdle. (I should be working on my survey
paper right now!) The nice thing is that I'll be able to fully dedicate
myself to this work during my three months at Google.
If you have any general questions, please feel free to ask. If you want
details about ra_serf, well, I don't know that just yet - that will have to
wait until I have the time to answer it in the detail it merits. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 27 09:00:37 2005