incubator-libcloud 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 Mon, 17 May 2010 22:36:42 GMT
No worries.. this whole thing is indeed confusing.

-Adrian

On Mon, May 17, 2010 at 3:32 PM, Ian Bicking <ianb@colorstudy.com> wrote:

> 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 <ferncam1@gmail.com> 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
> > >
> >
>
>
>
> --
> Ian Bicking  |  http://blog.ianbicking.org
>

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