Patch Set 5: No score; No score

Based on my C git series there will still need to be a few revisions to the JGit code before we can submit it.  The protocol isn't set in stone yet and I had to make a few changes to it to make it easier to implement within the context of C git.

Regarding the Gitlet proposal:  If the serve method of a Gitlet takes the servlet request/response then its still tied to the servlet API, just as much as if it was subclassing HttpServlet.  I'm not sure what removing that parent class gets us.  This isn't a portal system where we are going to want to include output from many different Gitlets to form a complete HTTP response.  Most of these responses are specific content meant for machine consumption in a well defined format.

I also really dislike the idea of putting the regex inside of each Gitlet because it makes it very hard to see the complete routing map for the server.  One of the hardest things to maintain within a web application is the mapping of URL to implementation.  The more concisely you can describe that mapping in as few locations as possible, the easier it is to maintain the application long term.

The RepositoryRouter and ServletDefinition were designed to allow me to bind servlets to URLs in a fashion similar to the way that Guice servlet works.  Of all of the Java web frameworks, I think the Guice servlet approach is the most concise-yet-flexible mapping I have seen.

We also have very few URLs we need to respond to for the HTTP based transport.  If we wanted to also support writing from older dumb WebDAV clients we could, probably with just what we already have defined.  If/when we ever implement a gitweb style interface we may very well want a lot more web framework than HttpServletRequest offers, and may want to put that into a different project entirely to compartmentalize the dependencies.

So, basically, my opinion is this Gitlet idea isn't worth the effort right now because I don't think the future will require it.