libcloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomaz Muraus <to...@cloudkick.com>
Subject Re: [libcloud] libcloud roadmap and plans for the future
Date Tue, 08 Feb 2011 14:58:22 GMT
On Tue, Feb 8, 2011 at 2:57 PM, Schwartz, Philip Marc (LNG-BCT) <
Philip.Schwartz@lexisnexis.com> wrote:

> I would also vote -1 to twisted. But 0 to async. I am for async to a point
> as long as it is setup as a per instance option for the user.
>

Yes, that is how I have envisioned it. I probably should have explained it
better in my original post.

The change should be non-disruptive and the Twisted dependency should be
optional (basically it would be totally up to the user if he wants to use
async API or not).

And like Paul has pointed out above, refactoring a library might not be a
bad idea, since we will need to split and refactor some of the existing
methods and this will make testing (among other things) easier.

Thanks,
Tomaz


>
> In other words making a secondary async http client library to allow usage
> if desired with no lasting effect on the core of libcloud. The moment we
> make a change as drastic as making the http client async will be the moment
> that we make people using the library a little angry as most would not want
> an async http client for compute work.
>
> Thank You,
> Philip Schwartz
> Software Engineering
> LexisNexis RS
> O - 561 999 4472
> C - 954 290 4024
>
>
> -----Original Message-----
> From: Upayavira [mailto:uv@odoko.co.uk]
> Sent: Monday, February 07, 2011 3:43 PM
> To: libcloud@incubator.apache.org
> Subject: Re: [libcloud] libcloud roadmap and plans for the future
>
> Personally, I'd be concerned if Libcloud took on Twisted. I (as
> something of an outsider) see Libcloud as a lightweight library for
> interfacing with cloud providers. If you add Twisted, you add a
> heavyweight dependency to a lightweight library, and suddenly deploying
> your Libcloud based apps becomes a whole lot harder, especially if
> you've never used Twisted.
>
> Upayavira
>
> On Mon, 07 Feb 2011 19:03 +0100, "Tomaz Muraus" <tomaz@cloudkick.com>
> wrote:
> > On Mon, Feb 7, 2011 at 4:04 PM, Jerry Chen <jerry@apache.org> wrote:
> >
> > >
> > > On Feb 7, 2011, at 8:48 AM, Tomaz Muraus wrote:
> > >
> > > > On Mon, Feb 7, 2011 at 4:57 AM, Jed Smith <jed@jedsmith.org> wrote:
> > > I agree. Speak up, people!
> > >
> > > BTW, I started up a wish list on the wiki a while back:
> > > http://wiki.apache.org/incubator/LibcloudWishlist
> > >
> > > I'm not convinced it has the best voting mechanism (it acts like a IRC
> > > topic vote!) but at least we can get an idea of the weighting.
> > >
> >
> > Cool, I have updated the wiki with other ideas.
> >
> > On Mon, Feb 7, 2011 at 4:24 PM, Jed Smith <jed@jedsmith.org> wrote:
> >
> > > On Mon, Feb 7, 2011 at 10:04 AM, Jerry Chen <jerry@apache.org> wrote:
> > > >
> > > > As long as the abstraction doesn't create weird race conditions, nor
> > > forces us to modify each driver for async stuff to work, I would be
> okay
> > > with this capability. I just can't wrap my head around how one would
> test
> > > for correctness and stability.
> > >
> > > I believe it would. You now need to track what requests you have out
> > > and call the appropriate callback, a very difficult (and tedious
> > > task). A supposedly stateless library just inherited a /lot/ of state.
> > >
> >
> > In Twisted and other event-driven system everything runs inside a single
> > thread (reactor) and as long you are only using asynchronous API, you
> > don't
> > need to worry about race conditions.
> >
> > In any case, adapting the library for async stuff would definitely
> > require
> > some refactoring, but I could argue that this might not be such a bad
> > idea.
> >
> > Anecdote: I solved this problem for the Linode iPhone app. If you're
> > > not familiar with UIKit/Foundation development for iOS, it's all
> > > asynchronous. I spent very many hours debugging the code that did the
> > > linkage between APIRequest instances and the callback event on them.
> > > It got so difficult to do properly with Apple's APIs that I eventually
> > > stumbled upon a hopelessly inelegant solution: every request the
> > > iPhone app makes is a batch, with a test.echo action containing an ID
> > > which is a key into the pending-requests dictionary. Seriously.
> > >
> > > That's what asynchronous ends up becoming in a request-receive
> > > environment. It's a rabbit hole of inelegant solutions and a lot of
> > > tedious state tracking in the library.
> >
> >
> > Yes, I agree, debugging in a lot of callback oriented frameworks can be a
> > huge pain. One of the good examples of this is NodeJS - with a lot of
> > nested
> > callbacks and no long stack traces finding a root cause can be pretty
> > painful (Twisted partially solves this with defer.SetDebugging(True)).
> >
> > So, yes, in general debugging and writing asynchronous code can be
> > painful,
> > but Twited has enough of syntactic sugar which makes it a lot less
> > painful
> > (deferreds, inlineCallbacks, ...).
> >
> >
> > > --
> > > Jed Smith
> > > jed@jedsmith.org
> > >
> >
>
> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law.  If
> you are not the intended recipient, you should delete this message.  Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited.
>

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