incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: [libcloud] Java Skeleton Available
Date Tue, 18 May 2010 20:24:40 GMT
It seems like what a user would want is a common cloud abstraction for different language bindings.
 Adrian, do you use the same resource model as Libcloud ?  If not, I can see that if people
like the LibCloud abstraction then different languages for the same abstraction is a plus.
 The language shouldn't drive the interaction model (for the most part anyway) :)

On May 17, 2010, at 6:27 PM, Adrian Cole wrote:

> 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
> -Adrian
> 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  |

View raw message