abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Server module refactoring
Date Sat, 19 Jan 2008 01:08:10 GMT
Ok, given the discussions around Adapter/CollectionProvider and the 
complex way the existing server code has evolved, I decided to take a 
step back and look at the server module as a whole.  I believe I've come 
up with a refactoring that will greatly simplify things overall and make 
it easier to support not only the capabilities that our friends from 
google want, but also things like extension methods (e.g. patch), 
protocol extensions (e.g. opensearch), etc.

Note: the refactoring would actually take place above the functionality 
that the google feed-server provides, so there could potentially be very 
little impact on that work, but we'll address that shortly.

The refactoring that I have in mind changes everything from 
AbderaServlet up through CollectionProvider and is focused on reducing 
the number of moving parts and number of things a developer has to do 
when implementing an atompub server.

In this note, I want to provide a quick run through of the changes I 
have in mind.  I'll post some of the preliminary implementation ideas to 
a jira issue.


Package: org.apache.abdera.protocol.server.refactor


Package: org.apache.abdera.protocol.server.refactor.impl


The code flow in the current implementation is:

   AbderaServlet -> RequestHandler -> Provider -> CollectionProvider

After refactoring, RequestHandler will be removed completely.  The 
Provider interface is simplified to a single request method.

There will be a single base abstract Provider implementation provided 
but advanced developers will be able to replace that implementation with 
their own.

The default provider implementation will extend 
AbstractWorkspaceManagerProvider.java.  This class implements boththe 
Provider and WorkspaceManager interfaces.

The WorkspaceManager is equivalent to the current WorkspaceInfo 
interface.  It's primary function is to lookup the appropriate 
CollectionAdapter instance.

CollectionAdapter is the equivalent to the current CollectionProvider 

MediaCollectionAdapter extends CollectionAdapter to provide methods for 
handling media resources.

A CollectionAdapter instance can choose to implement the Provider 
interface in order to support extension methods.

A CollectionAdapter instance can choose to implement the Transactional 
interface if it wishes to support begin/end/compensate semantics.

All of the methods on CollectionAdapter take RequestContext and return 
ResponseContext, maintaining the ability to parameterize requests and 
utilize streaming responses.

The flow is simple: request comes into the servlet, which dispatches to 
the Provider.  The Provider gets the WorkspaceManager and uses it to get 
the CollectionAdapter.  If the request is for a known method and a known 
target type, the provider dispatches to the appropriate method on 
CollectionAdapter (e.g. getFeed, deleteEntry, etc).  If the request is 
for an unknown method and an unknown target type, the provider checks to 
see if the CollectionAdapter implements the Provider interface, and if 
so, forwards the request on to it for processing, otherwise, an 
unsupported method response is returned.  If CollectionAdapter 
implements Transactional, all of this is preceeded by a 
Transactional.begin() and proceeded by Transactional.end().

A CollectionAdapter can be implemented that wraps the simplified Adapter 
interface used by feed-server.  Initially, this interface would not 
implement either Transactional or MediaCollectionAdapter keeping it in 
line with the current functionality offered by feed-server.

Additional refactorings would be required to implement this but overall 
the code structure would be greatly simplified, more logical, easier to 
extend, easier to maintain, and more accessible for end users.

Anyway, please take a look and let me know what you think.

- James

View raw message