> > 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 <[email protected]> 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 <[email protected]> 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 > > >
