David Primmer wrote:
I'll let Jun and Vasu respond in more detail later, but my general
impression of your comments is that they are not valuing the use case
that we were considering; namely that we wanted to make it easier to
produce an Atom interface to existing data sources that probably have
their own interface and accompanying local human administrative
expertise. We wanted to take the specifics of the Atom protocol out of
way of the dev in the same way that a high-level ORM can hide the
implementer from having to do SQL. That way, the user of the library
can focus on adapting the data sources and providing a read-write rest
web service.
Great, I think this is a very valuable use case.
What I'm confused about is why we need a new mechanism to do this. I
already went through and provided an example of how the
CollectionProvider can support both your needs and general developer
requirements.
Can you please provide some concrete examples of why the CP code cannot
be used or why the Adapter approach is easier to use? I roughly
understand what you're saying about how you're trying to focus on
adapting data sources, but I still don't see why this can't be done with
the CP code and why we need a completely new implementation/paradigm to
do it.
Would you be opposed to writing a AbstractDataSourceCollectionProvider?
(I don't really care that much about naming, but hopefully its clear
what I mean from the context). This would work with the existing
ServiceProvider, reuse the existing approach and provide you with the
interface you want.
If you're coding
the whole thing from scratch and agnostic to back-end storage format,
Adapter seems like a dumb name.
I never said it sounded dumb. I said it just wasn't consistent. I too am
not a huge fan of the *Provider naming, but thats a rabbit hole that we
can revisit later as its really not as important as the interfaces for
interacting with the system.
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
