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 19:04:58 GMT
I think its pretty typical at Apache that you try to gain consensus 
about controversial patches first.

Why the rush to stick it in SVN anyway? I'm sure we'll figure out what 
to do soon. We're having good healthy discussion :-)

- Dan

James M Snell wrote:
> I disagree. Putting the code into the repository does not commit us to 
> anything and gives us all a base from which to iterate.  Discussion 
> can and will still happen.
> - James
> Dan Diephouse wrote:
>> 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
http://mulesource.com | http://netzooid.com/blog

View raw message