Sorry -- I got my names confused; there was this talk of reimplementing libcloud in Java (where this thread started), and jclouds was mentioned, and I thought they were the same thing. I now see they are entirely different.
On Mon, May 17, 2010 at 5:27 PM, Adrian Cole <[email protected]> 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 <[email protected]> wrote: > > > On Mon, May 17, 2010 at 1:50 PM, Peter Haggar <[email protected]> > 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 > > > -- Ian Bicking | http://blog.ianbicking.org
