abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: FeedServer Review
Date Wed, 16 Jan 2008 14:52:06 GMT
I think its a little early to check code in as we're in the midst of a 
discussion about this still. Once the discussion wraps up I'm sure we'll 
have a clearer idea of what to do.

James M Snell wrote:
> 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
>>


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog


Mime
View raw message