FeedServer Review

[Dan Diephouse]

Here are my thoughts: When creating an entry, it is not sufficient to have just an Entry object. You need the whole RequestContext. This way you can access things like headers, an HTTP session, etc. For instance, in my application, the user has to supply an HTTP header when creating a media entry which provides some extra metadata. [1] This is why the CollectionProvider works at the RequestContext level. It doesn't handle media entries. Media entries are tricky. There is a lot of class.getName() and classloading going on which seems to build on Abdera's usage of this in the ServiceContext. I'm not a fan of this in general. IoC type frameworks should handle this for us and if you're using the API its much easier to just do setFoo(Foo.class) or even better setFoo(new Foo()); This is on my list to look at refactoring. There is no workspace level abstraction. See WorkspaceInfo inside the server module which can dynamically create workspaces in conjunction with ServiceProvider. For instance, I could have BlogWorkspaceInfo which was backed by a database of blogs. It would then return a series of CollectionProviders for each blog. (We could possibly return a less "heavy" object here, but creating a CollectionProvider should not be resource intensive). FeedServerProvider doesn't seem very fleshed out at all. There is no error handling framework. I don't like the term "Adapter" on its own as its pretty meaningless. I think there is something to be said for sticking with *Provider all around as its consistent. I would be consdier CollectionAdapter though. Keep in mind that AbstractCollectionProvider is *not* the only CollectionProvider there can be. Take a look at the raw CP interface and you'll see its a more powerful version of the Adapter interface. You can easily write your sample JdbcAdapter and SampleAdapter by using this interface. For instance, one could write a CollectionProvider like this: public class HowGoogleWantsToAccessFeeds implements CollectionProvider {   public ResponseContext createEntry(RequestContext request) {        Entry entry = createEntry(getEntryFromRequest(request));               entry = createEntry(entry);        ... do other stuff necessary with entry;   }   public Entry createEntry(Entry entry) {    ..... Use an entry how your adapter works now   } } Maybe AbstractCollectionProvider would be better renamed as Abstract(Simple/Object/Entity)CollectionProvider. Then we could abstract out some of the more common functionality for *all* CPs into AbstractCollectionProvider. For example this bit of code would be work for CollectionProviders:  public ResponseContext createEntry(RequestContext request) {     try {       MimeType contentType = request.getContentType();       if (isMediaType(contentType))         return createMediaEntry(request);       else         return createNonMediaEntry(request);     } catch (ParseException pe) {       .....     }   } The key here though is that this code *has* to be inside the CP. It cannot work at the feed level as you may want to override this logic for individual collections in a workspace/service. And you need the RequestContext to do this. This is why we need an interface like CollectionProviders and I think its much better to build adapters from CPs to whatever else you want like I showed above or how I did with AbstractCollectionProvider. Its looking to me like there are maybe some misunderstandings of the ServiceProvider/CP code. This idea that CPs cannot work at the "data" level is not correct. Hopefully that is clear from the above. Or maybe I am just not understanding what you mean. Can you clarify what exactly is missing? Or concrete improvements that you'd like to see? Or possibly patches? I know there are things in the API that definitely can be tweaked/improved. Maybe its not even the right paradigm, but the Adapter classes seem to be a weaker version of this paradigm. If anything I think we need to start focusing on other things: - How do we enable opensearch & paging on CPs - Can we build in better support for categories and comments threads? - Do we need to worry about concurrency issues in the model? etc. Cheers, - Dan 1. http://svn.galaxy.muleforge.org/browse/galaxy/trunk/web/src/main/java/org/mule/galaxy/atom/ArtifactCollectionProvider.java?r=210#l144 -- Dan Diephouse MuleSource http://mulesource.com | http://netzooid.com/blog