abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vasu Nori" <vasun...@gmail.com>
Subject Re: FeedServer Review
Date Wed, 16 Jan 2008 02:36:27 GMT
I have created a new issue in Jira to address adapters issue (key =
ABDERA-88).

thanks

On Jan 15, 2008 3:12 PM, James M Snell <jasnell@gmail.com> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message