Ok, I just about have the initial code drop ready to check in. There is an Ant build and a Maven build (thanks to Stephen Duncan!). The Eclipse project info has been removed. Detailed instructions on developing with eclipse will be included in the project site documentation.
Elias, Rob Yates and I are working on some server code. Our plan over the next couple of weeks is to build a number of simple, independent APP server implementations based on the Abdera core and parser code, compare the similarities between the implementations and abstract out a solid subset of functionality to seed the initial check-in. (We'll also be looking at Roller's Atom implementation). There are several goals in regards to the server code. First, we should NOT be trying to create some kind of service framework the likes of Axis2. The server implementation we produce will likely take the form of a collection of interfaces and utility classes that make it easier to build APP server implementations regardless of the application framework being used on the server (e.g. plain-ole-servlets, tapestry, struts, whatever). Second, the APP server implementation must be capable of working with multiple backend data stores. Essentially, an application using Abdera on the server will be responsible for plugging in a data store. Each data store implementation will be responsible for performing any necessary translation to-and-from the Atom constructs via the interfaces we'll provide. e.g. I want to be able to say DataSource.getCollection() and have it return a collection resource with a valid Atom feed attached to it. Our current development efforts have been focused on creating data stores based on the JCR (Jackrabbit), RDF, relational databases (Derby/DB2), and the file system. Regarding the core and parser code, there are several things we need from the community: 1. Test cases. The goal of Abdera's Atom parser is to be fairly liberal and forgiving. Input should be well-formed XML but does not necessarily have to be valid Atom. Date formats must be ISO-8601. We need to produce a library of test feed and entry documents that properly stress the parser and figure out where it breaks. 2. API review. The Feed Object Model interfaces in the core package are designed first to be a correct representation of the Atom data model. The usability of the API has been a concern and I'm certain it can be improved. It would be excellent if folks could review the API and offer feedback. What I'd like to do is freeze the core interfaces by the first milestone. 3. Ideas for the server and client code implementations. I'm a big fan of the shotgun approach -- that is, having multiple people go off and do their own thing with the code for a bit then coming together and combining the results. 4. I'd like to get a C/C++ implementation going... preferably based on a similar architecture (e.g. Axiom for C, perhaps). 5. Any other discussion / ideas / suggestions / gripes / contributions y'all feel like making :-) While I'm waiting for my user account to be set up (so I can check in the code), folks can use the code that is available from my personal website -- http://www.snellspace.com/public/abdera.tar.gz - James
