Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jasnell@gmail.com designates
 209.85.132.246 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=OdAyC4zPNUwR7iFexrHr7Ijol8ubjNAtvBJa7kdn1qDKzK1xAeV2cm6i66ONAqHfWN8mYJsNhpMRoIFPydQC9IUCL9lSIXuYkET/Qm93QN6zXQDF3QC/OemKBOYsIwpBxqbl1sXJ7EDW87J+7w3BiQVz3jW4YZORNQJZntztif0=
Message-ID: <478E27EB.303@gmail.com>
Date: Wed, 16 Jan 2008 07:51:07 -0800
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
Subject: Re: FeedServer Review
References: <478D20EF.4090902@mulesource.com>
 <ce54216b0801151454y56f3949cid35697222bbc97b3@mail.gmail.com>
 <478D3DEF.80601@gmail.com> <478E1A16.5070209@mulesource.com>
In-Reply-To: <478E1A16.5070209@mulesource.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>>>
> 
>