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 19:20:38 GMT
No particular rush, I just think better when there's code available ;-).
FWIW, I had been planning on putting the code into the contrib module 
for now, which, along with the fact that it doesn't change any existing 
classes, would make it a pretty zero impact check-in.

- James

Dan Diephouse wrote:
> 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
>>>>>
>>>
>>>
> 
> 

Mime
View raw message