Status and todo's

[James M Snell <ja...@gmail.com>]

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

Re: Status and todo's

[James M Snell <ja...@gmail.com>]

Garrett Rooney wrote:
>[snip]
> Great.  Be aware that it sometimes takes a few days to work its way
> through the system, but as soon as it's acked by the secretary (he has
> to put a note in a file in subversion saying that he got it) then I'll
> let this list know.
> 

Yep.

> Also, when did you fax in your CLA?  The last batch that was recorded
> by the secretary was on the 5th, so if it was before then, you might
> want to resend.  Sometimes the faxes he gets are unreadable, so
> resending is necessary.
> 

Faxed it on the afternoon of the 6th.

- James

Re: Status and todo's

[Garrett Rooney <ro...@electricjellyfish.net>]

On 6/8/06, James M Snell <ja...@gmail.com> wrote:
>
>
> Garrett Rooney wrote:
> >[snip]
> >> 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 ;-)
> >
>
> Sorry, wasn't clear.  These have been the goals up to this point and I'd
> like to recommend that these be the goals moving forward.

Excellent.  And to be clear, I think they're fine goals to have ;-)

> The grant is sitting here signed on my desk and will be faxed in this
> afternoon.

Great.  Be aware that it sometimes takes a few days to work its way
through the system, but as soon as it's acked by the secretary (he has
to put a note in a file in subversion saying that he got it) then I'll
let this list know.

Also, when did you fax in your CLA?  The last batch that was recorded
by the secretary was on the 5th, so if it was before then, you might
want to resend.  Sometimes the faxes he gets are unreadable, so
resending is necessary.

-garrett

Re: Status and todo's

[James M Snell <ja...@gmail.com>]

Garrett Rooney wrote:
>[snip]
>> 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 ;-)
> 

Sorry, wasn't clear.  These have been the goals up to this point and I'd
like to recommend that these be the goals moving forward.

>> 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.
> [snip]
> 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.
> 

My apologies.

>[snip]
>> 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.
> 

The grant is sitting here signed on my desk and will be faxed in this
afternoon.

- James

Re: Status and todo's

[Garrett Rooney <ro...@electricjellyfish.net>]

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

Re: Status and todo's

[Elias Torres <el...@torrez.us>]

yup. I just tested it by committing a dummy README file.

-Elias

James M Snell wrote:
> 
> Elias Torres wrote:
>> James M Snell wrote:
>>
>> [snip]
>>
>>> 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
>> I saw in the project page that they had our svn ids already. What do you
>> mean you are waiting for the user account to be set up?
>>
> 
> I'm waiting for my user account.  You, Sam, and Yoav already have id's.
> 
> - James
> 

Re: Status and todo's

[James M Snell <ja...@gmail.com>]

Elias Torres wrote:
> 
> James M Snell wrote:
> 
> [snip]
> 
>> 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
> 
> I saw in the project page that they had our svn ids already. What do you
> mean you are waiting for the user account to be set up?
> 

I'm waiting for my user account.  You, Sam, and Yoav already have id's.

- James

Re: Status and todo's

[Elias Torres <el...@torrez.us>]

James M Snell wrote:

[snip]

> 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

I saw in the project page that they had our svn ids already. What do you
mean you are waiting for the user account to be set up?

-Elias

> 
> - James
>