incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Davis <...@dislocatedday.com>
Subject Re: [libcloud] Polyglot Libcloud
Date Wed, 06 Oct 2010 18:16:51 GMT
>
> 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—outside of those produced by a company for use with their own tools,
APIs, etc.—that has implementations in multiple languages. Usually, a fork
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—do
they use the Python version or the Java version? What are the criteria for
the Python version keeping its "reference implementation" status—are other
versions simply compelled to lag behind regardless? How do we balance the
desire to create interoperable parts for all implementations with the desire
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 more
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
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message