Hi, Matt. Good point.
Last December, libcloud and us met and we (jclouds) decided to use the same naming conventions, which ended in us renaming things from Server -> Node, Flavor -> Size, etc. We've modeled a few things that libcloud doesn't, so our model is bigger. However, we do use the same names for the things that are in common. Cheers, -Adrian On Tue, May 18, 2010 at 1:24 PM, Matt Hogstrom <[email protected]> wrote: > 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 > >> > >
