abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vasu Nori" <vasun...@gmail.com>
Subject Re: meeting to discuss integrating FeedServer?
Date Mon, 14 Jan 2008 22:34:04 GMT
great comments, James.

IMHO, I think we have 2 potentially different concepts in CollectionProvider
& Adapter and they can coexist. let me explain.

CollectionProvider defines (and greatly simplifies) a server implementation
based on Abdera. The protocol handling part of it.

Adapter deals with the data - the methods to be implemented by the
datasources to do CRUD operations on data.

One (Collectionprovider) implements protocol handling mechanism and the
other (Adapter) handles data related issues. Datatsources shouldn't care
about inner workings of atom protocol and CollectionProvider mechanism
provides a great implementation mechanism without knowing about the details
of CRUD on data.

I agree with James point on transactional semantics in CollectionProvider.
should be moved to an adapter. The methods - begin(), end() - in
CollectionProvider seem to indicate maintenance of some sortof state between
server and the caller.

On Jan 14, 2008 1:48 PM, James M Snell <jasnell@gmail.com> wrote:

> 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.
> The CollectionProvider accepts a RequestContext in order to allow
> requests to be parameterized.  This is a good thing and needs to be
> preserved.
> 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.
> 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.
> - James
> Dan Diephouse wrote:
> > Agreed. I have some thoughts on the feedserver bits and I'll write them
> > up tomorrow. I'll get Jim Ancona's changes integrated as well then.
> >
> > James M Snell wrote:
> >> We could do a phone meeting, but I think it would help more helpful if
> >> we had the discussion here on the list.  I know it could take a bit
> >> longer, but doing so ensures that everyone will have a better chance
> >> of being able to weigh in.
> >>
> >> - James
> >>
> >> David Primmer wrote:
> >>> I don't know if everyone has had time to digest the code we posted
> >>> but I'd
> >>> like to setup a phone conference where we can go over some of the
> issues
> >>> around integrating FeedServer code into Abdera. I'd especially like to
> >>> discuss the design differences between Dan's implementation and ours
> (so
> >>> Dan, you'd be the guest of honor). I don't know if merge will be
> >>> possible
> >>> but we should discuss it. Let me know if you're interested.
> >>> thanks.
> >>>
> >>> davep
> >>>
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message