libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <fernc...@gmail.com>
Subject Re: [libcloud] Java Skeleton Available
Date Tue, 18 May 2010 20:28:53 GMT
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 <matt@hogstrom.org> 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 <ianb@colorstudy.com>
> wrote:
> >
> >> On Mon, May 17, 2010 at 1:50 PM, Peter Haggar <pfhaggar@gmail.com>
> 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
> >>
>
>

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