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: <AANLkTinYi35NnDc1Mfd6Vm4DJm9MArpMQaqlhbIGKbhQ@mail.gmail.com>
References: <AANLkTilM0UFF3-yOh6g4nwrvpm07f86pZFFJ9QL9ZTsn@mail.gmail.com>
	<AANLkTinYi35NnDc1Mfd6Vm4DJm9MArpMQaqlhbIGKbhQ@mail.gmail.com>
From: Tom Davis <tom@dislocatedday.com>
Date: Wed, 19 May 2010 01:51:33 -0400
Message-ID: <AANLkTikemCgBoPL4DDci2_VwsrJoojTrlTt0vPbVnM0a@mail.gmail.com>
To: libcloud@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e656b7420f91400486ec0eb2
Subject: Re: [libcloud] Java Skeleton Available

--0016e656b7420f91400486ec0eb2
Content-Type: text/plain; charset=ISO-8859-1

I've been following this discussion for a while now and figured I'd finally
throw my two cents in. Sorry if it's mostly already been said...

Perhaps the "lib" prefix is a bit of a misnomer, but I don't think we
intended for libcloud to be a library upon which bindings were written.
Given the rate of change in cloud APIs and the fact that any new addition
may require fundamental structural changes to accommodate it, it doesn't
make much sense as one because the bindings would have to fundamentally
change in the same way quite often. Perhaps once we've had the time and
experience to get an API-stable 1.0 release it would make more sense, but
that would then require rewriting basically the entire project for what I
perceive as a limited gain.

There are more maintainable ways to make libcloud available to more than
just pure-Python applications. The easiest of these include a CLI addition
and an XMLRPC server. The latter could even be altered to allow multiple
clients via non-blocking connection libraries, a la Twisted. I wrote
libcloud's core in a way to make this as trivial a change as possible, with
the expectation that it would eventually be adapted to other networking
engines for expressly such a purpose (and hopefully others I haven't thought
of!)

 Look at libcloud as a kind of reference implementation and just live
> with it.


This is another possibility, though I was quite upset to see the interfaces
be deleted since they were a well-documented and implementation-free
reference for how one would make a libcloud-compliant API. At least somebody
(Paul?) went through and added some comments to base class methods...

libcloud has grown quite a bit since its inception. Even so, it still has a
ways to go and fragmenting the community to deal with multiple forks doesn't
strike me as a great idea since we're just now at a 0.3 release. I think
it's absolutely awesome that people have liked and trusted in what we've got
here enough to want to already base multi-language APIs off of it and I see
no reason why that shouldn't be done. However, I don't think it should be
the responsibility of this particular project to grow, manage, and maintain
those forks.

There are just too many Python-based extensions that can be added to make
libcloud even more useful to more people (especially those who don't use
Python) that it seems more efficient to manage those (and the likelihood of
continued support and success for them would be more likely, in any event).

On Wed, May 19, 2010 at 12:02 AM, Ian Bicking <ianb@colorstudy.com> wrote:

> On Tue, May 18, 2010 at 7:48 PM, Peter Haggar <pfhaggar@gmail.com> 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
> task.
>
> 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
> implementations.
>
> 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
> well.
>
> 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  |  http://blog.ianbicking.org
>

--0016e656b7420f91400486ec0eb2--