incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Bicking <>
Subject Re: [libcloud] Java Skeleton Available
Date Wed, 19 May 2010 04:02:33 GMT
On Tue, May 18, 2010 at 7:48 PM, Peter Haggar <> wrote:

> 2) Rewrite the engine in C, or better yet Java, to enable any programmer
> regardless of language to use libCloud.  This also has the benefit of only
> having a single code base to change for maintenance/API changes, etc.  If
> we
> choose Java, perhaps parts of jclouds could be used for this so we don't
> have to start from scratch.  We are already working on a Java engine, so we
> will be donating what we have and that could be used as well, in whole or
> in
> part.

As a Python user Java would not be useful to me.  Jython is only used by a
small minority of Python users, and interacting with the Java runtime is not
easy or widely done.  For people who use the JVM it would be nice, but the
JVM is not that universal.  C would be much easier to integrate, but still a
terrible nuisance, and C would be a *terrible* language for this kind of

I see a couple possibilities of how to do this without being completely
disruptive to what libcloud has done so far:

1. Look at libcloud as a kind of reference implementation and just live with
it.  Try to make the implementation as demonstrative as possible, using
clear well-documented patterns that can be translated and tracked among

2. See if libcloud implementations can become DSL-like, where drivers are
primarily data-driven.  This might mean pulling significant chunks of code
out of drivers and making them "general" despite the fact that only one
provider needs a particular chunk of code, but that's not the end of the
world.  Other implementations could use the same data and track libcloud at
a more abstract level.  Ideally the test suite could become data-driven as

3. Express libcloud operations as some kind of data and API, so you could
interact with libcloud without running the code in-process.  You could
potentially run a small server that could be interacted with (maybe using
XMLRPC or JSONRPC), or interact with a command-line client as I suggested
earlier.  Once a data (not object) representation of the public objects is
created (nodes, sizes, etc) then it wouldn't be too hard to try implementing
multiple APIs building on that data.

Ian Bicking  |

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