libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <>
Subject Re: [libcloud] Java Skeleton Available
Date Mon, 17 May 2010 22:27:54 GMT
jclouds wrapping libcloud... It's hard to wrap something that didn't exist
yet!  Moreover libcloud functionality is a subset of jclouds, which is
perfectly appropriate to the scope of this project.

jclouds public history is longer than libcloud, albeit only 3 or 4 months.
I watched the birth of libcloud, through the weird name conflict with the
now deltacloud, watched you guys add drivers, and chatted over dinner with
paul about what is now the deploy api.  I have applauded libcloud publicly
along the way, with the exception of this particular issue.  I'd like us to
all focus on what we do best and not unnecessarily cause confusion.

Anyhow, congrats on trolling me just now :p

On Mon, May 17, 2010 at 3:06 PM, Ian Bicking <> wrote:

> On Mon, May 17, 2010 at 1:50 PM, Peter Haggar <> 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  |

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