[libvirt] [RFC] Events API

[Richard W.M. Jones]

On Thu, Sep 18, 2008 at 12:45:07PM -0400, David Lively wrote:
>   I'm a little concerned that a vector of event type names isn't really
> adequate for specifying a filter.  Does this need to be more general
> (XPathString exprs??)

I think I'm with Dan on this one.  I would start small -- just domains
coming & going (unless VirtualIron needs other events).  Since there
is no limit to the number of API calls we can have in libvirt, add an
API call just for registering for these domain events.  Instead of
trying to overload untyped strings with complicated meanings.

>   But my larger concern is that an asynchronous callback mechanism (as
> proposed above) assumes the presence of some thread / process from which
> to make the callbacks.  This works fine in the libvirtd context, but
> not outside of it.  For instance, we build a "client only" version of
> libvirt with ONLY the remote driver, which currently doesn't require
> pthreads at all.  Introducing asynchronous callbacks into the API means
> pthreads is now required for this.

I'm not quite sure I follow this -- you mean it introduces pthreads
into libvirt or into the caller?  As far as I can see, nothing about
this would require threads in either.

The remote protocol allows event messages to be passed back
asynchronously, although the current remote driver wouldn't expect to
receive them which might be a problem for backwards/forwards
compatibility.  (Therefore the remote client must tell the remote
server that it can handle asynchronous events, and the remote client
must be prepared to talk to a server which cannot understand
asynchronous events -- there is an internal feature API you can use
for this).  Notwithstanding that, you would have to add a client call
to poll for events or (better) to expose the file descriptor so that
callers can use it in select(2)/poll(2).

Actually there are a number of ways to do this -- IIRC dbus does
something semi-elegant.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora