abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: Simplifying Server Side Development
Date Sat, 15 Sep 2007 10:16:35 GMT
I'm thinking about a couple changes which would improve this mechanism a 
bit. First, I think the whole ContentInfo thing should go and it should 
just use the Content object instead.

Second, I think instead of making ContentProvider so high level, it 
could be modeled after the Provider interface a bit more. This 
ContentProvider would continue to handle the work of manging the 
Collection, but it would provide access to the Request/ResponseContext. 
There could then be an AbstractSimpleContentProvider which looks like 
ContentProvider does now. This would allow more low level access to the 
Entry/Feed/etc when needed.

This would mean there would be essentially 3 levels:
1. Provider - manages the whole APP service
2. ContentProvider (maybe better called CollectionProvider?) & 
WorkspaceInfo: These provide metadata about the workspace and back the 
3. AbstractSimpleContentProvider - provides simple APIs like "T 
getEntry(String id)" which users could override.


- Dan

James M Snell wrote:
> Dan, very cool to see you thinking through this stuff. Give me a couple
> of days to stew on it and I'll post some thoughts next week.
> - James
> Dan Diephouse wrote:
>> Hi All,
>> I think there is some agreement that server side development needs to be
>> made a bit easier. This last week I've been hacking on a way to make it
>> as easy as possible, yet still be fairly extensible. I think its a
>> rather naive first attempt and I don't know if I've succeeded at all, so
>> I was hoping to get some feedback.
>> The basic idea is that you write against the ContentProvider interface
>> and "fill in the blanks". I.e.
>> BlogProvider extends ContentProvider<BlogEntry> {
>>   public String getTitle(BlogEntry b) {
>>     return b.getName();
>>   }
>> ....
>> }
>> It is FAR from done. For instance:
>> 1. No exception handling of any kind - i.e. no way to throw a 404
>> 2. Doesn't provide ways to map things like categories or other metdata
>> on the entry.
>> 3. Resolver/Provider URL handling needs to come together somehow (per my
>> previous thread)
>> 4. I have no idea if this is even conformant to the atompub spec, I'm
>> really just making this up as I go along - so it could seriously suck.
>> How IDs are supposed to work is particularly fuzzy. (I know I have to
>> read that part of the Atompub spec soon, but I wanted to get this out
>> here for feedback)
>> 5. The example/test is a very naive attempt to figure out what it would
>> be like to expose a customer database over AtomPub.
>> 6. Not sure I like how the classes are named
>> 7. Apache license headers aren't in tack, figure it needs more work
>> anyway before committing
>> Code is here:
>> https://issues.apache.org/jira/browse/ABDERA-63
>> Cheers,
>> - Dan
>> PS I'm gathering that the conversion stuff James recently committed may
>> play along with the whole idea of simplifying things a bit for server
>> side developers. James: any chance you can give us a run down of the
>> ideas behind it?

Dan Diephouse
http://mulesource.com | http://netzooid.com/blog

View raw message