[egit-dev] Smart HTTP Git server general observations

[Alex Blewitt <alex.blewitt@xxxxxxxxx>]

Having looked through the code, I do have one observation that is  
different from my prototype. Currently, the parent of the hierarchy is  
RepositoryServlet, which fields incoming requests and performs  
standard functionality (like the location of the repository on disk).  
Individual actions are available as subclasses of this (InfoServlet  
etc.) but these are non-public classes and can't really be used as  
servlets in their own right.

I believe we should have a layer of abstraction, like a Gitlet, which  
represents the non-servlet parts of the RepositoryServlet, and then  
have a GitServlet (which uses the servlet parts of RepositoryServlet)  
to do the same kind of delegation as before. We could also handle the  
HEAD/GET differences at the GitServlet level and provie a unified API  
for the Gitlet to be able to handle.

In other words, we'd go from something like this:

* RepositoryServlet extends Servlet
|- InfoServlet
|- PackServlet
|- RefsServlet
...

to this:

* RepositoryServlet extends Servlet
* Gitlet
|- InfoGitlet
|- PackGitlet
|- RefsGitlet

The RepositoryServlet would still act as a router (e.g.  
bind(RefsGitlet.INSTANCE)) but the Gitlet would take on the  
getRepository functionality, provide an easy way of obtaining the sub- 
path ("info/refs") and provide  unified API for accessing/sending the  
data. Whilst functionally this is not different from before, it would  
mean that the *Servlets (which couldn't be used as direct servlets  
anyway; they rely on the REPOSITORY request attribute to be stamped  
first) are in fact not servlets, and therefore doesn't matter if  
they're public or not. One could imagine, at a future date, having  
some kind of registration process (like OSGi services) providing  
implementations of Gitlets dynamically.

In addition, the Gitlet could provide a (sub) regexp, like "info/ 
refs", and the current bind() functionality could be replaced with  
just an instance pointer (instead of an instance/regexp pair) which  
would allow new Gitlets (like GerritGitlet) to be added subsequently  
and without changing any of the RepositoryServlet code (which  
currently has a hard-coded mapping of regexps). Lastly, the Gitlet  
would be the level at which optimisations (like supporting range  
requests) could be implemented.

Incidentally, this is the same kind of pattern that Restlet uses (www.restlet.org 
) and the kind of pattern I was working towards, so the fact that it  
has evolved separately here is encouraging :-)

Alex