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
