> > > 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. > - 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 > > 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 > > > -- Vasu Nori ext: 41643 650.214.1643 (direct) 925.209.0647 (c) [EMAIL PROTECTED]
