incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Jackson <foamd...@gmail.com>
Subject Re: [libcloud] Java Skeleton Available
Date Sat, 22 May 2010 03:27:07 GMT
Hi,

I'm following this with interest, how is libcloud defined by the
implementation language?

Right now we seem to have some people who would prefer not to add
further language bindings beyond python (for pragmatiic/no-time, don't
want to have distractions beyond getting the current implementation
through incubation etc).  There is a proposal of submitting a java
version of libcloud to be under the same umbrella project as the
current implementation.

I don't see how adding a different language binding is going to cause
a fragmented community, or prevent development going forward.

Part of going through the incubation process is the fact that there
will be more participants, with wider points of view and these will
conflict.  Resolving the conflicts allows teh gestalt community to
form and this community then makes the decisions on how things
progress within the project.

Based on the correct way of resolving conflict in apache projects - I
propose a vote - this removes all ambiguity and prevents accusations
of back room deals etc.
http://www.apache.org/foundation/voting.html

libcloud is a python project and should remain purely python
throughout incubation
YES [ ]
NO [ ]

libcloud is a an abstraction interface for various cloud hosing
service providers, the current implementation happens to be python,
but other bindings for Java etc will make libclouds more convenient
YES [ ]
NO [ ]

And for what it's worth, my (non-binding vote)

libcloud is a python project and should remain purely python
throughout incubation
YES [ ]
NO [x] (and by implication -0, I won't stand in the way and I will
help with the python version even if the rest of the developers decide
that this should be the only version of apache libclouds)

libcloud is a an abstraction interface for various cloud hosing
service providers, the current implementation happens to be python,
but other bindings for Java etc will make libclouds more convenient to
the userbase
YES [x] (and by implication +1 - I'm happy to help provide alternative
language versions of libcloud - my preferences being ruby/erlang/c)
NO [ ]

Thanks,
Kev

Mime
View raw message