Currently I think one of our weaknesses is the resolving mechanisms.
While I think we're close, I think it'd be helpful to just outline some
requirements so we're all on the same page. Here's my list:
While I see the value in regexes, users find it highly uncool to have to
define their URI structure in several places. i.e. I do not want to have
to supply the same information to the resolver and the CollectionAdapter
(via getHref()). (I've heard this from at least 3 people)
Things should come configured out of the box to work correctly with the
minimum amount of configuration necessary. I think I did this with my
changes to the WorkspaceManager/CollectionAdapter, but I don't think its
the perfect implementation. All one has to do is specify the
CollectionAdapter href and they're good to go. They can get more
complicated from there: they can override the Provider
href/servicesPattern. If thats not enough, they can override
CollectionAdapter.getHref() and supply their own target resolver.
It should be easy to attach other things to the service like opensearch
definitions.
It should be easy to reuse a Provider in multiple locations.
It should be easy to override the default resolution mechanism.
We must address the problem that with the current regex resolver, we are
not able to distinguish between media and atom-entry POSTs to the same
URL as its based on the content type. (See the code in the
StructuredResolver which does this).
--
I think the APIs are fairly close. Its just a matter of tweaking and
getting the default implementation to be reasonable. Right now I set up
the StructuredResolver so everything works by default. It finds an
appropriate CollectionAdapter during the resolution then stuffs it in
the RequestContext. Inside AbstractProvider we call
WorkspaceManager.getCollectionAdapter() and the DefaultWorkspaceManager
pulls it back out.
This violates the "it should be easy to attach other things..."
requirement though. Maybe a hybrid regex/structured approach is worth
investigating?
I need to think about this for a little bit, but I thought I'd throw it
out there.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
