libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Bicking <i...@colorstudy.com>
Subject Re: [libcloud] Java Skeleton Available
Date Mon, 17 May 2010 22:06:30 GMT
On Mon, May 17, 2010 at 1:50 PM, Peter Haggar <pfhaggar@gmail.com> wrote:

> Now, this brings up something else I wanted to get some feedback on.  One
> issue with libCloud is that when you want to bring it to another language,
> like Java or something else down the road, it requires a port of the
> engine,
> plus the different provider adapters.  Should we consider a different
> approach?  For example, what if we wrote the engine in C and provided a C
> interface for the APIs (reboot_node, create_node, list_images, etc).  This
> way I can write my code in any language and just call out to C to interface
> with the libCloud library.  Yes, this would require a rewrite of the
> exising
> Python base to C, but it would put to rest the language discussions as well
> as give us a single engine to maintain, vs. multiple.  I think this could
> be
> a positive step forward and really broaden the appeal of libCloud.
> Thoughts?
>

The performance characteristics of libcloud are such that you could call out
to a subprocess to import libcloud and do an operation, and it wouldn't be
terrible overhead.  Since everything libcloud does tends to be slow (i.e.,
makes a network connection with some API) there's no a big advantage a
native implementation.  There are API advantages... like native exceptions,
introspectable interfaces, general style, etc.  But there's not really any
getting around the reimplementation of those things on a per-language basis.

It might be nice, for instance, if there was a clear JSON representation of
all the native libcloud objects, you could do things like:

python -c "import libcloud, sys, json
obj = make_object_from_data(json.loads(sys.argv[1])
method = getattr(obj, sys.argv[2])
args = []
kw = {}
pos_args = sys.argv[3:]
while pos_args:
    if pos_args[0].startswith('--'):
        if '=' in pos_args[0]:
            keyword, value = pos_args[0][2:].split('=', 1)
            pos_args.pop(0)
        else:
            keyword = pos_args[0][2:]
            value = pos_args[1]
            pos_args = pos_args[2:]
        kw[keyword] = json.loads(value)
    else:
        args.append(json.loads(pos_args.pop(0))
result = method(*args, **kw)
json.dumps(make_data_from_object(result))
"

OK... that's silly as a -c argument.  But still with appropriate
implementations of make_object_from_data and make_data_from_object you turn
libcloud into a kind of command-line program.  And maybe libcloud could ship
something like this?  E.g., if you run "python -m libcloud".

On the subject of jCloud, I'm a little surprised it didn't just use Jython
and wrap libcloud, implementing a Javaish API around it.  Then from there
you could reimplement pieces in Java as needs required, and maybe mostly
share test cases and perhaps let the drivers for smaller services stay in
Jython indefinitely.


-- 
Ian Bicking  |  http://blog.ianbicking.org

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