Post 0.3.0

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

I've been wanting to ask, what kind of stuff would folks be interested
in seeing post 0.3.0?

The basic Atom and Atom Publishing impl is complete but I'm certain we
can make additional refactorings.

The http client cache implementation is functional but it's definitely
not perfect.

The server module can definitely continue to be refactored.  The
contributions from Brian and Dan have been excellent and I hope to see
more :-)

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.

I've got some code that allows Abdera elements to be sent over XMPP.

Does anyone have anything else in mind?

- James

Re: Post 0.3.0

[Brian Moseley <bc...@osafoundation.org>]

On 8/28/07, James M Snell <ja...@gmail.com> wrote:

> The one concern I'd have on this one is that these kinds of marshalling
> frameworks tends to get rather complicated very quickly.  I abhor
> needlessly complicated code.  If this can be achieved in a generally
> simple and elegant way then I'm all for it.  Do you have anything in
> mind for an impl?

the basic requirements would be:

* register an object that converts between model and content
* during feed generation, convert a model object to entry+content
* during entry creation/update, convert entry+content to a model object

i have to admit that my attempt at this in cosmo, while not
particularly complex, is nowhere near elegant. i'm happy if the notion
bakes in folks' mind for a while. maybe somebody will have a
particularly bright idea, or stumble across a pattern or similar
implementation elsewhere that we can use here.

> A search/filter capability would definitely be interesting.  Again, my
> main concern would be complexity.  There also aren't a lot of standards
> to back this up.  As above, do you have anything in mind for an impl?

again, nothing directly useful to abdera at the moment. in cosmo we
specify projection and format as uri path extensions following the
portion of the path that actually identifies the resource. i don't
much like specifying filtering this way. i suppose query string
parameters are the way to go, but i find them so aesthetically
unappealing ;)

i'll continue to use cosmo as a lab and suggest particularly promising
ideas here.

Re: Post 0.3.0

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

Brian Moseley wrote:
> On 8/27/07, James M Snell <ja...@gmail.com> wrote:
>> 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.
> 
> definitely the most awkward area of my implementation is how to
> serialize my domain model into some format suitable as entry content,
> and how to deserialize an incoming entry to apply it to the model,
> especially when there are multiple possible representations for a
> model object. it would be nice if abdera provided a nice utility for
> this, since everybody has to do it.
> 

The one concern I'd have on this one is that these kinds of marshalling
frameworks tends to get rather complicated very quickly.  I abhor
needlessly complicated code.  If this can be achieved in a generally
simple and elegant way then I'm all for it.  Do you have anything in
mind for an impl?

> i'd also like to consider extensions like: how does a client give
> hints to the server about what specific data it wants included in a
> feed? google's data apis have the concept of "projections" that
> essentially filter the data in the feed. and there's the choosing a
> representation question above. sometimes the client might even want to
> tell the server "a full entry might include these ten columns from the
> database table, but i only want columns A, C and F".
> 

A search/filter capability would definitely be interesting.  Again, my
main concern would be complexity.  There also aren't a lot of standards
to back this up.  As above, do you have anything in mind for an impl?

- James

Re: Post 0.3.0

[Brian Moseley <bc...@osafoundation.org>]

On 8/27/07, James M Snell <ja...@gmail.com> wrote:
> 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.

definitely the most awkward area of my implementation is how to
serialize my domain model into some format suitable as entry content,
and how to deserialize an incoming entry to apply it to the model,
especially when there are multiple possible representations for a
model object. it would be nice if abdera provided a nice utility for
this, since everybody has to do it.

i'd also like to consider extensions like: how does a client give
hints to the server about what specific data it wants included in a
feed? google's data apis have the concept of "projections" that
essentially filter the data in the feed. and there's the choosing a
representation question above. sometimes the client might even want to
tell the server "a full entry might include these ten columns from the
database table, but i only want columns A, C and F".

> 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.

i wouldn't expect a 1.0 to be released until after graduating, but i'm
not sure there are any hard and fast rules.

Re: Post 0.3.0

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

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 <ja...@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

Re: Post 0.3.0

[Dan Diephouse <da...@envoisolutions.com>]

On 8/27/07, James M Snell <ja...@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
-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog