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 Wed, 16 Jan 2008 15:51:07 GMT
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

View raw message