integrating FeedServer

[Jun Yang <jy...@gmail.com>]

Hi all,

I am another developer on FeedServer.

> My initial thoughts on this are simple: the converter mechanism that I
> began in fall but haven't been able to complete should likely be dropped
>
> in favor of an approach based on the StreamWriter/StreamBuilder
> mechanism.  The Adapter and CollectionProvider mechanisms should be
> merged.  We should use the Adapter interface name for the merged result.
>
> Our effort should and will definitely support StreamWriter/StreamBuilder.

We picked the adapter name because it's a widely recognized pattern.
FeedServer's main use is to convert from any other protocol and data format
to APP and ASF.  So we think this is an appropriate name for the job it
does.

> The CollectionProvider accepts a RequestContext in order to allow
> requests to be parameterized.  This is a good thing and needs to be
> preserved.
>
> Adapter interface doesn't depend on RequestContext for a good reason: we
want the adapters to be easily reusable outside the context of Abdera.  It's
easy to add another layer that takes a RequestContext, where streaming is
done, to wrap adapters.

> The CollectionProvider also provides methods for transactional
>
> semantics.  These could be pushed to a subclass, e.g.
> TransactionalAdapter, in order to simplify things a bit.
>
> We need to figure out how to make it easier to extend the functionality
> of this stuff.  The Provider interface is set up to make it possible to
>
> use extension HTTP methods (e.g. MOVE, PATCH, etc) but this is not
> passed on to either CollectionProvider or Adapter.  There needs to be an
> elegant extension mechanism.
>
> The fact that CollectionProvider returns ResponseContext objects makes
> it possible for us to use StreamWriter to write out the responses.  The
> Adapter interface is currently only capable of returning FOM objects.
> While this certainly does simplify things, it limits the flexibility and
>
> performance
>
> Agreed.  An adapter wrapper can take RequestContext and do streaming.

> The Adapter interface should become part of the server project.
> Specific Adapter implementations can also be added to server or they
> could go into their own module.  It would be extremely valuable to have
> a number of stock Adapter implementations available
>
> Agreed.   We picked JDBC first for that reason.  We wanted this
contribution to be useful from day one.

> - James
>
> Jun