Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: esme-dev@incubator.apache.org
Subject: Re: Just added API2 Java client to SVN
Date: Mon, 7 Dec 2009 09:46:38 -0500
User-Agent: KMail/1.12.4 (Linux/2.6.32-gentoo; KDE/4.3.4; x86_64; ; )
Cc: Ethan Jewett <esjewett@gmail.com>
References: <fa2d9f450912061456y569ebc3fndc875e09bdd376f5@mail.gmail.com>
 <68f4a0e80912061611h2406f847ub7911bfeb4c5a678@mail.gmail.com>
In-Reply-To: <68f4a0e80912061611h2406f847ub7911bfeb4c5a678@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200912070946.39540.dkulp@apache.org>

On Sun December 6 2009 7:11:13 pm Ethan Jewett wrote:
> Hi,
> 
> While I'm a huge fan of having API client libraries galore, I don't
> think it's a very good idea to maintain them in the actual ESME
> repository. There are several reasons for this:
> 
> 1. Most client library authors will not be commiters, creating an
> unnecessary bottle-neck around library checkins.

Umm.....  Why wouldn't they be committers?

With my mentor hat on, this statement kind of concerns me.  One of the goals 
of the project in the incubator is to broaden the appeal of the product and 
broaden the committer base.   Statements like the above seem relatively 
exclusive.


Why SHOULDN'T clients pertaining to ESME not be part of ESME.    I would think 
that interacting with ESME is pretty important.   Getting client developers on 
board with the project is probably a good thing.  It can get more people using 
ESME and thus new ideas and such.

Dan


> 
> 2. There may be more than one version of a client in a given
> language/platform, and we probably shouldn't be playing favorites.
> 
> 3. Checking them in as part of the project gives a sort of "Apache
> stamp of approval", which we may indeed want to give, but should
> probably do by listing the clients on the wiki rather than checking
> them into the repository.
> 
> Overall, I'd say that the general approach for API clients to projects
> like this is for authors to maintain them in public repositories
> (usually Github or Google Code, depending on the choice of version
> control system). They can then be managed outside of the Apache
> process.
> 
> Often, an implementation will provide a reference client in one or
> more languages, not meant for production use. If that is what we are
> trying to do here, then I guess I could come around to supporting that
> position, but we should be aware that we are signing up for more work
> 
> :-)
> 
> Wow, I'm such a contrary person aren't I? Richard (and others) what do
> you think? Were you going for "reference client" or were you planning
> for this to happen for all clients?
> 
> Ethan
> 
> On Sun, Dec 6, 2009 at 4:56 PM, Richard Hirsch <hirsch.dick@gmail.com> 
wrote:
> > FYI
> >
> > I just added Daniel's initial code drop
> > (https://issues.apache.org/jira/browse/ESME-14) for a Java client for
> > the streaming API to SVN.
> >
> > D.
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog