abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Primmer" <david.prim...@gmail.com>
Subject Re: FeedServer Review
Date Tue, 15 Jan 2008 22:54:50 GMT
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.

The use case you seem to be focused on is targeting a developer of a
custom application that has an Atom interface which is more tightly
coupled to the data it is publishing. There's nothing wrong with a
more monolithic approach where the programmer controls all aspects of
the application, including storage and api and it may even allow a
cleaner or simpler design. This has probably been the primary use case
of Abdera at this point and it may be in the future. This allows much
more flexibility and optimization and should be available to those who
want to use it.

Tell me if this seems accurate: I see all these arguments as simply
presenting the case for different uses of Abdera. These server
implementations all pick an arbitrary points to stop putting
constraints on the user. Our approach is more product-oriented,
favoring 'convention over configuration' and you are sticking closer
to the open framework roots of Abdera. Isn't there a way that both can
exist in the codebase without confusing the developer?

On Jan 15, 2008 1:09 PM, Dan Diephouse <dan.diephouse@mulesource.com> wrote:
>  Here are my thoughts:
> There is no workspace level abstraction. See WorkspaceInfo inside the server
> module which can dynamically create workspaces in conjunction with
> ServiceProvider. For instance, I could have BlogWorkspaceInfo which was
> backed by a database of blogs. It would then return a series of
> CollectionProviders for each blog. (We could possibly return a less "heavy"
> object here, but creating a CollectionProvider should not be resource
> intensive).

We made efforts to not duplicate your workspace design and were aware
that our server implementation did not have this level of abstraction.
This was in anticipating of merging with your code.

> I don't like the term "Adapter" on its own as its pretty meaningless. I
> think there is something to be said for sticking with *Provider all around
> as its consistent. I would be consdier CollectionAdapter though.

The term Provider acts like a gaussian blur to my eyes. And generally
adds nothing to whatever it is attached to. What is a Provider?
Adapter at least hints at the fact that it changes something from one
format to another while allowing the endpoints to connect easily.
Again, this is a matter of the product design perspective you come
from. Were looking at using this with legacy data. If you're coding
the whole thing from scratch and agnostic to back-end storage format,
Adapter seems like a dumb name.

hope this helps.


View raw message