further thoughts on abdera versus feedserver

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

I was talking with the team here today and we thought that it was a good
idea to move the majority of the code from FeedServer to Abdera. We're not
convinced that shutting down the FeedServer project is a good idea though.
We think that keeping FeedServer alive as a packaged version of Abdera
should be its role going forward.
Our additions to Abdera like the Adapter Class have and will be moved to
Abdera.

We plan on running a build on c.g.c that pulls from Abdera and generates
specific runtime configurations. This could be a really easy to use,
out-of-the-box server that has a few adapters chosen. This may turn out to
be the reference implementation for the API server for Shindig or it may be
a couple different feature sets. All changes to core functionality will be
coded in the Abdera codebase. We assume this path will make it easier to be
a downstream project, since we'll be depending on the jars and we can manage
version dependencies.

We have some tests that depend on jMock right now and we'd like those to
stay in the FeedServer project until they can be ported to the Abdera trunk.

The one thing that we're thinking we'd like to keep in feedserver is ongoing
adapter implementation development. I know that James has said that he'd
like Adapters to be contributed to Abdera, but I see a potential for clean
separation. We're hoping, for example, that third parties would write
adapters and not necessarily commit them to Abdera. Because we stabilize and
simplify the interface, it's possible to treat an adapter implementation
like a plugin that is packaged and distributed separately. It still may be
worthwhile to have some basic ones, like the JDBC adapter in Abdera.

please let me know what you think of this plan.

davep

Re: further thoughts on abdera versus feedserver

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

This sounds fine, especially since I suspect that y'all will want to 
implement some adapters with fairly google/gdata specific 
extensions/features.

As part of the server factoring, the core the feed-server stuff has been 
worked in, although Dan and I share some concerns about the limitations 
of the Adapter interface (BasicAdapter in the server refactoring). 
Within the Abdera core, we could probably just provide the basic 
mechanisms and if y'all want to keep the restricted methods, it is very 
simple to create an abstract CollectionAdapter implementation that makes 
that happen (see BasicAdapter).

- James

David Primmer wrote:
> I was talking with the team here today and we thought that it was a good 
> idea to move the majority of the code from FeedServer to Abdera. We're 
> not convinced that shutting down the FeedServer project is a good idea 
> though. We think that keeping FeedServer alive as a packaged version of 
> Abdera should be its role going forward. 
> 
> Our additions to Abdera like the Adapter Class have and will be moved to 
> Abdera.
> 
> We plan on running a build on c.g.c that pulls from Abdera and generates 
> specific runtime configurations. This could be a really easy to use, 
> out-of-the-box server that has a few adapters chosen. This may turn out 
> to be the reference implementation for the API server for Shindig or it 
> may be a couple different feature sets. All changes to core 
> functionality will be coded in the Abdera codebase. We assume this path 
> will make it easier to be a downstream project, since we'll be depending 
> on the jars and we can manage version dependencies.
> 
> We have some tests that depend on jMock right now and we'd like those to 
> stay in the FeedServer project until they can be ported to the Abdera trunk.
> 
> The one thing that we're thinking we'd like to keep in feedserver is 
> ongoing adapter implementation development. I know that James has said 
> that he'd like Adapters to be contributed to Abdera, but I see a 
> potential for clean separation. We're hoping, for example, that third 
> parties would write adapters and not necessarily commit them to Abdera. 
> Because we stabilize and simplify the interface, it's possible to treat 
> an adapter implementation like a plugin that is packaged and distributed 
> separately. It still may be worthwhile to have some basic ones, like the 
> JDBC adapter in Abdera. 
> 
> please let me know what you think of this plan.
> 
> davep
> 
> 
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google 
> Groups "Google FeedServer" group.
> To post to this group, send email to google-feedserver@googlegroups.com
> To unsubscribe from this group, send email to 
> google-feedserver-unsubscribe@googlegroups.com
> For more options, visit this group at 
> http://groups.google.com/group/google-feedserver?hl=en
> -~----------~----~----~----~------~----~------~--~---
>