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 vasunori@gmail.com designates
 66.249.82.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Ph4kMNLfdUmxSDomja9yCR7d7OJQn1o8EvA3Zah7LkwTonrvV0injVDp6daeTvFQmiyGYneLQfxt4gQfNtsPMaG25W2eA3FZzbyYDA3V2vVc02vvedu3gUVwBpnJDWLrMpdwXetWUovcHdU42a7fzSVGhEInTbv8u8oE3RdsOoQ=
Message-ID: <41a5ab360801161127q566c518cg355184960106ebfc@mail.gmail.com>
Date: Wed, 16 Jan 2008 11:27:06 -0800
From: "Vasu Nori" <vasunori@gmail.com>
To: abdera-dev@incubator.apache.org
Subject: Re: FeedServer Review
In-Reply-To: <478E19D8.1010402@mulesource.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_17998_11594407.1200511626738"
References: <478D20EF.4090902@mulesource.com>
	 <ce54216b0801151454y56f3949cid35697222bbc97b3@mail.gmail.com>
	 <478E19D8.1010402@mulesource.com>

------=_Part_17998_11594407.1200511626738
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I looked at JcrCollectionProvider.java.
Dan is right - CollectionProvider is **like** Adapter - with a few
differences.

1. In the Adapter code, AdapterManager looks at the <feed>.properties file
to figure  out which adapter class to load to serve the given feed.  In the
usecases that we have encountered, we cannot assume that the server always
knows about ALL the feeds it needs to serve. Datasources can be dynamically
added which provide new feeds - and when the server receives a request with
a new feedname in it, it needs to load the corresponding datasource adapter
(connector or collectionprovider - whatever you want to call it).

2. properties file also includes certain other properties for feeds such as
title, author, database sqlmap file name(if required) etc. I don't like
hardcoding of any configurable attributes in java files.

3. CollectionProvider(or, whatever we want to call it) only needs to have
code that deals with accessing data from datasource. Any other code that
DOES NOT deal with data from/to datassource - I would rather put it in a
different class. Thats what we did by separating code into
FeedServerProvider.java and Adapter(s).java.

4. Can people write their own "collectionProviders"? sure. but why do that
when we can make it easier by shipping a whole bunch of "adapters" (or
collectionprovders) for most common datasources - all types of databases,
filesystem etc. It was one of your stated goals that we should make writing
a server easier.

5. CollectionProvider can't be the one serving "service document".
especially, since the server dynamically can expand the set of feeds it is
serving (see point#1 above). we thought FeedserverProvider.java could be the
place to have that code.

The more I think about it, the more convinced I am that Dan's code is not
that far away from our code. things can tweaked a little here or little
there - but I would have happier if we agree on the concepts first..hope
that makes sense.

thanks

On Jan 16, 2008 6:51 AM, Dan Diephouse <dan.diephouse@mulesource.com> wrote:

>
> David Primmer wrote:
> > I'll let Jun and Vasu respond in more detail later, but my general
> > impression of your comments is that they are not valuing the use case
> > that we were considering; namely that we wanted to make it easier to
> > produce an Atom interface to existing data sources that probably have
> > their own interface and accompanying local human administrative
> > expertise. We wanted to take the specifics of the Atom protocol out of
> > way of the dev in the same way that a high-level ORM can hide the
> > implementer from having to do SQL. That way, the user of the library
> > can focus on adapting the data sources and providing a read-write rest
> > web service.
> >
> >
> Great, I think this is a very valuable use case.
>
> What I'm confused about is why we need a new mechanism to do this. I
> already went through and provided an example of how the
> CollectionProvider can support both your needs and general developer
> requirements.
>
> Can you please provide some concrete examples of why the CP code cannot
> be used or why the Adapter approach is easier to use? I roughly
> understand what you're saying about how you're trying to focus on
> adapting data sources, but I still don't see why this can't be done with
> the CP code and why we need a completely new implementation/paradigm to
> do it.
>
> Would you be opposed to writing a AbstractDataSourceCollectionProvider?
> (I don't really care that much about naming, but hopefully its clear
> what I mean from the context). This would work with the existing
> ServiceProvider, reuse the existing approach and provide you with the
> interface you want.
> >  If you're coding
> > the whole thing from scratch and agnostic to back-end storage format,
> > Adapter seems like a dumb name.
> >
> I never said it sounded dumb. I said it just wasn't consistent. I too am
> not a huge fan of the *Provider naming, but thats a rabbit hole that we
> can revisit later as its really not as important as the interfaces for
> interacting with the system.
>
> - Dan
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
>

------=_Part_17998_11594407.1200511626738--