Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[egit-dev] Smart HTTP Git server general observations

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 ( ) and the kind of pattern I was working towards, so the fact that it has evolved separately here is encouraging :-)


Back to the top