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: FeedServer Review
Date Thu, 17 Jan 2008 23:00:35 GMT
Jun Yang wrote:
> Hi Dan,
>
> We were very happy when we first saw your stuff.  We even tried to see if we
> should just subclass your provider.  But in the end we didn't because we
> thought it would take too much time to first influence the code to support
> dynamic adapter and then move to it.  We decided to release ours first,
> receive some feedback and then merge.
>   
I don't have any problem with that. What I do have issues with is 
throwing two mechanisms into the codebase when we could just address 
your use cases and try to fill the gaps. We just need to understand what 
those issues are.

> We have always planned to copy your support for Workspace and all into our
> provider.  
Are we talking about the feedserver codebase here or Abdera?
> So I think going forward, we can:
>
>    1. Enhance AbstractProvider to support workspaces, etc. and pick other
>    features to merge
>   
We've already got AbstractServiceProvider which handles workspaces. Can 
you please explain why we need another mechanism?
>    3. Keep Adapter as is
>   
I've already highlighted the limitations of the Adapter interface. 
Specifically it can't handle things like headers & media entries. Which 
if we're going to make any type of prebundled atom stores (i.e. JDBC or 
JCR), then this will need to be addressed. In essence the Adapter needs 
to take RequestContext as a parameter and return a ResponseContext. As 
soon as you do this to the Adapter interface you'll realize that is 
pretty much the exact same thing as the CollectionProvider. So I stand 
by my assertion that the Adapter interface itself is pretty redundant 
and I think we should stick with/enhance whats in there.

- Dan

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


Mime
View raw message