abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: Post 0.3.0
Date Mon, 27 Aug 2007 23:55:21 GMT
I haven't really dug into any detail on specific refactorings for the
server module.  I like the idea of having some way of allowing an
implementor to provide builder objects to use with a default provider
implementation; I'm just not sure how best to go about it.

Regarding the versioning; I'm sure the other committers have their own
thoughts on this, but I had originally considered keeping all incubation
releases as 0.N and only doing a 1.0 release only after we graduate.
Doing so gives us an excuse to keep things fluid and not lock down the
API too prematurely and allows us to get plenty of field experience with
the code to shake out any bugs.  N.0 releases always seem so official
and rigid :-).  That said, I wouldn't have any strong objections to
putting out a 1.0 in the not too distant future.

- James

Dan Diephouse wrote:
> On 8/27/07, James M Snell <jasnell@gmail.com> wrote:
>> After 0.3.0 goes out, I'll be checking in the first bits of the
>> annotations stuff.  It's still definitely a work in progress.
> IMO, whats needed most is stuff to simplify server side development. This is
> next on my list to really dive into, so I'm anxious to see what you've come
> up with in this area. Right now its really up to the user to know how to use
> the Abdera API. I'd like to see a more "fill in the blanks" type approach.
> Much less of a chance of the user (aka me) screwing things up. Maybe
> something like:
> public interface FeedProvider<T> {
>     String getAuthor();
>     String getId(T doc);
>     String getTitle(T doc);
>     String getTitle();
>     Date getUpdated(T doc);
>     void createContent(Entry e, T doc); // it gets a bit stickier here
> }
> Although I have no idea if thats really feasible or not.
> I've got some code that allows Abdera elements to be sent over XMPP.
> Sweet...
> My naive impression is that it does seem that most of the stuff at this
> point is a layer on top instead of major refactoring inside. It may be good
> to make the next release 0.9 or something where the API is cleaned up, and
> then move to a 1.0. Additional features could then be tacked on to 1.xreleases.
> - Dan

View raw message