You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by Dan Diephouse <da...@mulesource.com> on 2007/09/14 14:53:45 UTC
Simplifying Server Side Development
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
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: Simplifying Server Side Development
Posted by James M Snell <ja...@gmail.com>.
It's been on my todo list. I was going to take a look a bit later this
week.
- James
Dan Diephouse wrote:
> Anyone had a chance to look at this at all? I updated the patch a while
> back to make it a lot more cleaner/extensible/dynamic..
>
> - Dan
>
> Dan Diephouse wrote:
>> 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
>> collcetions
>> 3. AbstractSimpleContentProvider - provides simple APIs like "T
>> getEntry(String id)" which users could override.
>>
>> Regards,
>>
>> - 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?
>>>>
>>
>>
>
>
Re: Simplifying Server Side Development
Posted by Davanum Srinivas <da...@gmail.com>.
James,
+1 from me. I've been running tests since yesterday on that code.
-- dims
On 9/25/07, James M Snell <ja...@gmail.com> wrote:
> Dan, I've just finished going through this. It looks very good to me.
> If none of the other comitters object, I'll go ahead and check it in.
>
> - James
>
> Dan Diephouse wrote:
> > Anyone had a chance to look at this at all? I updated the patch a while
> > back to make it a lot more cleaner/extensible/dynamic..
> >
> > - Dan
> >
> > Dan Diephouse wrote:
> >> 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
> >> collcetions
> >> 3. AbstractSimpleContentProvider - provides simple APIs like "T
> >> getEntry(String id)" which users could override.
> >>
> >> Regards,
> >>
> >> - 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?
> >>>>
> >>
> >>
> >
> >
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
Re: Simplifying Server Side Development
Posted by Dan Diephouse <da...@mulesource.com>.
On idea that I had earlier (possibly late in the late) was to make a
CollectionProvider implementation that used the conversion context
stuff. But I'm not sure I understand the master plan behind the
conversion stuff, so I may be on crack. If nothing else, the patch I've
submitted will make it simple for (hopefully) 80% of the users who are
writing server impls to get started. There is more work to do yet
definitely*, but hopefully this will be a good start for the 0.4 release.
* I'm thinking primarily of the conversion context bits and providing
better unification between resolvers/providers.
Cheers,
- Dan
James M Snell wrote:
> There is definitely some overlap that will need to be worked out.
>
> - James
>
> Brian Moseley wrote:
>
>> On 9/25/07, James M Snell <ja...@gmail.com> wrote:
>>
>>> Dan, I've just finished going through this. It looks very good to me.
>>> If none of the other comitters object, I'll go ahead and check it in.
>>>
>> how does it relate to the conversion stuff you were working on?
>>
>>
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: Simplifying Server Side Development
Posted by James M Snell <ja...@gmail.com>.
There is definitely some overlap that will need to be worked out.
- James
Brian Moseley wrote:
> On 9/25/07, James M Snell <ja...@gmail.com> wrote:
>> Dan, I've just finished going through this. It looks very good to me.
>> If none of the other comitters object, I'll go ahead and check it in.
>
> how does it relate to the conversion stuff you were working on?
>
Re: Simplifying Server Side Development
Posted by Brian Moseley <bc...@osafoundation.org>.
On 9/25/07, James M Snell <ja...@gmail.com> wrote:
> Dan, I've just finished going through this. It looks very good to me.
> If none of the other comitters object, I'll go ahead and check it in.
how does it relate to the conversion stuff you were working on?
Re: Simplifying Server Side Development
Posted by James M Snell <ja...@gmail.com>.
Dan, I've just finished going through this. It looks very good to me.
If none of the other comitters object, I'll go ahead and check it in.
- James
Dan Diephouse wrote:
> Anyone had a chance to look at this at all? I updated the patch a while
> back to make it a lot more cleaner/extensible/dynamic..
>
> - Dan
>
> Dan Diephouse wrote:
>> 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
>> collcetions
>> 3. AbstractSimpleContentProvider - provides simple APIs like "T
>> getEntry(String id)" which users could override.
>>
>> Regards,
>>
>> - 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?
>>>>
>>
>>
>
>
Re: Simplifying Server Side Development
Posted by Dan Diephouse <da...@mulesource.com>.
Anyone had a chance to look at this at all? I updated the patch a while
back to make it a lot more cleaner/extensible/dynamic..
- Dan
Dan Diephouse wrote:
> 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
> collcetions
> 3. AbstractSimpleContentProvider - provides simple APIs like "T
> getEntry(String id)" which users could override.
>
> Regards,
>
> - 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
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: Simplifying Server Side Development
Posted by Dan Diephouse <da...@mulesource.com>.
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
collcetions
3. AbstractSimpleContentProvider - provides simple APIs like "T
getEntry(String id)" which users could override.
Regards,
- 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
MuleSource
http://mulesource.com | http://netzooid.com/blog
Re: Simplifying Server Side Development
Posted by James M Snell <ja...@gmail.com>.
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?
>