Announcing Google FeedServer

[David Primmer]

Hello,

I'd like to announce a little project that we've been working on for a while at Google and would like the feedback of the Abdera community. We're really excited about the potential of Abdera and have chosen it as the foundation for an open-source Atom Publishing Protocol Server. We hope that the approach we've taken is helpful to those who would like to create read/write Atom feeds for existing data sources. 

There are more details below, but I just wanted to give a quick update on where we'd like to go from here. We have lots of plans for the FeedServer, and would like to contribute back to the Abdera project. The FeedServer was conceived as a separate product and could possibly be an Abdera sub-project when it graduates from incubator. We are also considering how we will use it for the Data API portion of the Shindig project. For now, we have a project on Google's Codesite that should give people the opportunity to look it over and offer feedback:

http://code.google.com/p/google-feedserver/

We think we have some good docs up on the Codesite wiki. To dive in and see what we've done, we've created an intro to the source code for developers

http://code.google.com/p/google-feedserver/wiki/SourceCodeWalkthrough

Feel free to discuss here or join the Google group for the FeedServer.

Special thanks to Jeff Pitman, Jun Yang, Vasu Nori, Chris Anderson, Sanjay Baberwal, Jeff Scudder, Brandon Nutter James Snell, DeWitt Clinton and Mark Stahl. 

davep

[James M Snell]

Hello Dave,

Very happy to see this. After quickly reading through the docs and
browsing the source, there looks to be some very valuable function
provided, much of which I think could easily become part of Abdera.

The Adapter mechanism looks particularly good but I would like to see if
we could get some closer alignment between this and the work that Dan
Diephouse has been doing, and the new StreamWriter, StreamBuilder and
(poorly-named) EntityProvider mechanisms. For performance reasons, it
would really be ideal if Adapter implementations could use the
StreamWriter interface for serializing feeds and entries.

I do notice that the FeedServerProvider is currently rather limited in
function (e.g. no service document, no media post support, no feed
paging). I assume these functions will be added over time?

Oh, and are you aware that Abdera already has a MethodOverrideFilter? :-)

- James

David Primmer wrote:
> Hello,
> I'd like to announce a little project that we've been working on for a while
> at Google and would like the feedback of the Abdera community. We're really
> excited about the potential of Abdera and have chosen it as the foundation
> for an open-source Atom Publishing Protocol Server. We hope that the
> approach we've taken is helpful to those who would like to create read/write
> Atom feeds for existing data sources.
>
> There are more details below, but I just wanted to give a quick update on
> where we'd like to go from here. We have lots of plans for the FeedServer,
> and would like to contribute back to the Abdera project. The FeedServer was
> conceived as a separate product and could possibly be an Abdera sub-project
> when it graduates from incubator. We are also considering how we will use it
> for the Data API portion of the Shindig project. For now, we have a project
> on Google's Codesite that should give people the opportunity to look it over
> and offer feedback:
>
> http://code.google.com/p/google-feedserver/
>
> We think we have some good docs up on the Codesite wiki. To dive in and see
> what we've done, we've created an intro to the source code for developers
> http://code.google.com/p/google-feedserver/wiki/SourceCodeWalkthrough
>
> Feel free to discuss here or join the Google

> group<http://groups.google.com/group/google-feedserver>for the

[Vasu Nori]

---------- Forwarded message ----------
From: Vasu Nori <vn...@google.com>
Date: Jan 11, 2008 10:08 AM
Subject: Fwd: Announcing Google FeedServer
To: vasu...@gmail.com

The Adapter mechanism looks particularly good but I would like to see if
we could get some closer alignment between this and the work that Dan
Diephouse has been doing,

Yes, we haven't done that yet. Hope to touch base with Dan after he gets a chance a to review the code.
 

and the new StreamWriter, StreamBuilder and
(poorly-named) EntityProvider mechanisms.  For performance reasons, it
would really be ideal if Adapter implementations could use the
StreamWriter interface for serializing feeds and entries.

totally agree. Streaming is fantastic and we will have to implement it.

I do notice that the FeedServerProvider is currently rather limited in

function ( e.g. no service document, no media post support, no feed

paging).  I assume these functions will be added over time?

agreed.

Regarding service document, I'd like to add a point though.
The way Google feedserver is architected allows new feeds to be added at runtime (by simply adding a new adapter, adapter properties file & sending a new feed URI to the feedserver). Initially, when the system comes up, there are no known feeds to the server; i.e., service document = empty.
As each new feed URI comes in, the corresponding adapter is instantiated.
so, the service document gets built up overtime.

If at any point in time, a request for service document is received, google feedserver can return the service document known UNTIL that point in time. This is yet to be implemented though.

Oh, and are you aware that Abdera already has a MethodOverrideFilter? :-)

aha. didn't know that.. :)

thanks for the comments/suggestions.

[David Primmer]

Dan, we had long discussions about the CollectionProvidor approach and we do think it's a good approach. We wanted to get what we had out (some written before we saw your code) and then discuss the differences. We anticipate using both.We wanted a system that didn't require the dev to re implement all the basic atom crud for each collection and only specify the data translation rules. 

WorkspaceProvidor is an example of an area that we didn't work in because we anticipated using your stuff. So this is just a start of our Abdera work. It's not finished or finalized or anything.

davep

On Jan 11, 2008 9:59 AM, Dan Diephouse <dan.di...@mulesource.com> wrote:

Hiya,

Were there any thoughts on why the CollectionProvider/ServiceProvider
code was not a suitable approach? Did you look at possibly bringing the
two approaches together?

- Dan

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

[Vasu Nori]

On Jan 11, 2008 10:14 AM, David Primmer <david....@gmail.com> wrote:

Dan, we had long discussions about the CollectionProvidor approach and we do
think it's a good approach. We wanted to get what we had out (some written
before we saw your code) and then discuss the differences. We anticipate
using both.We wanted a system that didn't require the dev to re implement
all the basic atom crud for each collection and only specify the data
translation rules.

This is referring to the Adapter approach.

one of the goals of google-feedserver was to separate the 2 concerns: atom protocol implementation and data operations (CRUD) on the datasources.

all classes in com.google.feedserver.server package implement logic to handle atom protocol - of course, brains behind this whole code is Abdera.

all classes in com.google.feedserver.adapter package implement the logic to do CRUD on data from the datasources. Hopefully, this part is something other Abdera developers/users can utilize..

vasu