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