MediaCollectionAdapter shouldn't extend CollectionAdapter (methinks)

[Neale Upstone <ne...@nealeupstone.com>]

Hi James and others,

I'm currently designing an application for which I've chosen APP as the
protocol and I'm looking to use Abdera for the server nuts and bolts.

The scenario that I have is that I want to provide independent
CollectionAdapters for entries and media, and use the RouteManager to
select between them.

For example, my RouteManager will be configured as:
        routeManager = new RouteManager()
            .addRoute("feed", ":collection", TargetType.TYPE_COLLECTION,
            entriesAdapter )
            .addRoute("entries", ":collection/:entry",
            TargetType.TYPE_ENTRY, entriesAdapter)
            .addRoute("media", ":collection/:entry/:version/",
            TargetType.TYPE_MEDIA, mediaAdapter);

I have two challenges with the current (almost-1.0) release:

1) I don't see why I should need to implement the non-media methods on
my mediaAdapter.  I believe that CollectionAdapter and
MediaCollectionAdapter should not be in the heirarchy that they are.  I
suggest that MediaCollectionAdapter should just represent the
responsibilities of dealing with media.

Note: It already looks like this is assumed to be the case in the code,
e.g.:
   public abstract class AbstractCollectionAdapter implements
   CollectionAdapter, MediaCollectionAdapter, ...

2) The ManagedProvider class (and hence BasicProvider) assumes that
there is only one CollectionAdapter, and therefore leaves us having to
cook our own Managed-style implementation for my scenario.

Simply put, both of the above cause complexity in not allowing
separation of concerns.  I'd much rather see a simple out of the box
configuration where a BasicProvider can be supplemented with a
MediaCollectionAdapter.

I think a good measure for the community would be that we should be able
to mix and match different CollectionAdapter and MediaCollectionAdapter
implementations.  e.g. we may want to store entries in a database, and
media to disk.

Cheers,

Neale

-- 
  Neale Upstone
  neale@nealeupstone.com