On 6/8/06, James M Snell <[EMAIL PROTECTED]> wrote:
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).
Wouldn't it make more sense to bring those implementations to this
mailing list, so we can all participate in the process of finding
those similarities and abstracting out a subset of functionality?
There are several goals in regards to the server code.
I think you mean that you'd like these to be the goals, but as a group
we need to discuss them first ;-)
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).
This seems reasonable to me.
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.
Also, sounds fine.
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.
I obviously don't object to any of this, but I just want to point out
the danger of coming to the table with hardwired expectations. There
is bound to be some discussion of this sort of thing, and that should
happen here, on these mailing lists.
Regarding the core and parser code, there are several things we need
from the community:
Umm, what's the distinction here between "we" and "the community".
There's no us and them here, there's only us. If there are things
you'd like to see other members of the community pick up, that's fine,
but drawing lines like that is not useful.
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 :-)
Again, I don't have any objection to any of these (although personally
I'm not so keen on the idea of basing the C impl on Axiom for C, but
that's a debate we can have later), but be careful to avoid implying
that there's a subset of tasks that new people can work on, and a
subset that the initial contributors can work on.
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
Excellent, I'm sure people will want to take a look at the current
state of the code, and I'll keep an eye out for the CLAs and Grant so
we can get things moving along within the repository.
-garrett
