abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Status and todo's
Date Thu, 08 Jun 2006 17:40:32 GMT
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

View raw message