abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: FeedServer Review
Date Tue, 15 Jan 2008 23:12:47 GMT
Yep, the two approaches can certainly coexist, we just need to work out 
the details.  The first step needs to be getting the Adapter stuff 
checked in (or, at the very least, get a jira issue opened) and then 
start iterating from there.

- James

David Primmer wrote:
> [snip]
> 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.
> davep

View raw message