Mailing-List: contact libcloud-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: libcloud@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <1286388027.7981.6518.camel@urgyen>
References: <4862C3B7-848B-45B8-8300-93134DAEACC7@apache.org>
 <AANLkTi=xJ8taRMu0n1xasTCFHuhTS_LzJk8fCLP1W9Du@mail.gmail.com>
 <1286388027.7981.6518.camel@urgyen>
From: Tom Davis <tom@dislocatedday.com>
Date: Wed, 6 Oct 2010 11:16:51 -0700
Message-ID: <AANLkTim32Zaz-HR9jQxO1naqM+or=5ZGznvuNw2ffJFs@mail.gmail.com>
To: libcloud@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016362839a646f1f50491f6c910
Subject: Re: [libcloud] Polyglot Libcloud

--0016362839a646f1f50491f6c910
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

>
> And what happens when someone offers an implementation of XYZHosting API
> to Java libcloud. Will we accept it if there is no matching API for
> Python libcloud? Does Java always need to stay behind the 'reference'
> Python version?


These are the sorts of issues that led me to always feel a clear fork made
more sense for both communities. I can't think of a single open source
library=97outside of those produced by a company for use with their own too=
ls,
APIs, etc.=97that has implementations in multiple languages. Usually, a for=
k
is "inspired" by an existing project or is just a wholesale port to another
language. Very rarely are they so directly involved with one another,
though.

What happens when someone creates a command line interface using libcloud=
=97do
they use the Python version or the Java version? What are the criteria for
the Python version keeping its "reference implementation" status=97are othe=
r
versions simply compelled to lag behind regardless? How do we balance the
desire to create interoperable parts for all implementations with the desir=
e
to improve the individual versions by fixing bugs and adding more features?

These are questions that wouldn't need to be answered if non-Python
implementations were more autonomous. We'd have fewer headaches and
theoretically better products, since different implementations would be mor=
e
likely to compete on quality instead of trying to stay in sync.

On Wed, Oct 6, 2010 at 11:00 AM, Upayavira <uv@odoko.co.uk> wrote:

> And what happens when someone offers an implementation of XYZHosting API
> to Java libcloud. Will we accept it if there is no matching API for
> Python libcloud? Does Java always need to stay behind the 'reference'
> Python version?
>
> Upayavira
>
> On Wed, 2010-10-06 at 10:08 -0700, Paul Querna wrote:
> > On Wed, Oct 6, 2010 at 9:57 AM, Jerry Chen <jerry@apache.org> wrote:
> > > Hi all,
> > >
> > > I'd like to open for discussion the state of a multilingual Libcloud
> and what it means to be part of the official repository.
> >
> > Thanks for starting the discussion.
> >
> > > While we have kept the Java port in its own sandbox, I think there
> needs to be more discussion and reconciliation of APIs before we
> "officially" endorse the Java port.
> > >
> > > How can bring the Java port closer to the feature set of the original
> API? How can we share test suites so there is coverage outside of Python?
> >
> > Agree, we have no litmus test for what it means.  For example, I'm
> > personally thinking about making a Node.js port of libcloud, but would
> > desperately like to avoid writing new test cases.
> >
> > Speaking specifically for Java, I think there are the following issues:
> >
> >  1) Syncing the API as much as possible.  This needs review from
> > multiple people, I don't think it has happened yet.
> >
> >  2) Buildup of a test framework, preferably re-using some of the
> > python based test system.
> >
> >  3) Adherence to ASF policy licensing wise;  We need to run RAT
> > <http://incubator.apache.org/rat/> over the code base and fix up the
> > issues.
> >
> > 4) Make a release.
> >
> > 5) Continue growing the number of committers contributing to it.  This
> > also means probably adding new committers :)
> >
> > > Further down the road, I can see two scenarios for a Python and Java
> Libcloud existence:
> > > 1) both fall under the larger Libcloud umbrella and work together to
> maintain a common goal; tests are written, features are developed and
> matured in Python and then adopted/ported elsewhere; or,
> > > 2) the Java port becomes unofficially associated with Libcloud and
> adopts a different name to avoid confusion.
> > >
> > > Hope that makes sense.
> > >
> > > Thanks,
> > > Jerry
>
>
>

--0016362839a646f1f50491f6c910--