meeting to discuss integrating FeedServer?

[David Primmer <da...@gmail.com>]

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

Re: meeting to discuss integrating FeedServer?

[David Primmer <da...@gmail.com>]

On the list is fine. I thought we may be able to move quicker and summarize
things to the list. But if you all want it on the list, that's fine with me.
davep

On Jan 14, 2008 11:28 AM, Garrett Rooney <ro...@electricjellyfish.net>
wrote:

> On Jan 14, 2008 2:15 PM, James M Snell <ja...@gmail.com> 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.
>
> +1, keeping discussions on the list is generally best all around.
>
> -garrett
>

Re: meeting to discuss integrating FeedServer?

[Garrett Rooney <ro...@electricjellyfish.net>]

On Jan 14, 2008 2:15 PM, James M Snell <ja...@gmail.com> 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.

+1, keeping discussions on the list is generally best all around.

-garrett

Re: meeting to discuss integrating FeedServer?

[Vasu Nori <va...@gmail.com>]

>
>
> > 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.
> >
> These don't imply any kind of server state.  They are simply used for
> scenarios where you want to start/stop the local database transaction.
>
> - Dan


local database = database on the server?

to me, it is confusing see non-REST methods being declared in core abdera
interfaces which may be implemented by the user while building an
Abdera-based server.
To simplify the server implementation, I would like to have just the
necessary and sufficient interfaces/classes from Abdera to implement the
server, which will handle Atom protocol completely.
anything extra, could be an extension that the user may or maynot wish to
implement - but not part of the core classes..

Re: meeting to discuss integrating FeedServer?

[Dan Diephouse <da...@mulesource.com>]

Vasu Nori wrote:
> 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.
>   
These don't imply any kind of server state.  They are simply used for 
scenarios where you want to start/stop the local database transaction.

- Dan

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog

Re: meeting to discuss integrating FeedServer?

[Vasu Nori <va...@gmail.com>]

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 <ja...@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
> >>>
> >
> >
>

Re: meeting to discuss integrating FeedServer?

[James M Snell <ja...@gmail.com>]

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
>>>
> 
> 

Re: meeting to discuss integrating FeedServer?

[Dan Diephouse <da...@mulesource.com>]

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
>>


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog

Re: meeting to discuss integrating FeedServer?

[James M Snell <ja...@gmail.com>]

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
>