libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Bicking <i...@colorstudy.com>
Subject Re: [libcloud] Java Skeleton Available
Date Mon, 17 May 2010 22:32:16 GMT
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