Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of rooneg@gmail.com designates
 64.233.184.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=IPUfj5ngb6nLBz5X7vzTcEZlRf99qeNgf0d6ei45ge/1YOCHbVxHh6thGf979H5l8QaxfiiNQw9BM6LzccgmU8wpd30Xn7sXgYjBVUZGc8BnxDIRN8znFVUMv+c0hHr/j+jS1amKfkCOKIVLAW99XsM92sVybW2BzwHq9frmSTg=
Message-ID: <7edfeeef0606081103t49ca4c4p108b2aefd4460c88@mail.gmail.com>
Date: Thu, 8 Jun 2006 14:03:21 -0400
From: "Garrett Rooney" <rooneg@electricjellyfish.net>
Sender: rooneg@gmail.com
To: abdera-dev@incubator.apache.org
Subject: Re: Status and todo's
In-Reply-To: <44886110.1040200@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44886110.1040200@gmail.com>

On 6/8/06, James M Snell <jasnell@gmail.com> 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