abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Primmer" <david.prim...@gmail.com>
Subject further thoughts on abdera versus feedserver
Date Thu, 24 Jan 2008 20:00:32 GMT
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

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