Here are my thoughts:

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