EventNotifierFramework

Summary

Rationale

There are various events on a desktop system that people should be told about. For example, they may want to be informed if there are new updates available, if a ubuntu cd is detected in the cd-drive, if a new usb-soundcard was attached to the system, or if they run out of disk space. An event notification framework can avoid the need for many separate daemons for each of these tasks.

The goal is to unify the service of gnome-volume-manager, update-notifier (and it's post-update hooks) and a not-yet-written soundcard event daemon.

Use cases

Scope

Design

Implementation

From a mailing list message:

On Tue, May 31, 2005 at 12:56:04PM +0200, Martin Pitt wrote:

> (4) Create an universal, modular, and extensible common desktop
>     hotplug client "event-notifier". Throw away update-notifier and
>     gnome-volume-manager and implement their functionality into
>     modules of event-notifier.
>   + Clean design, should be extensible with
>     "/etc/desktop-hotplug-foo/{device,package,log,gamin}.d/<module>"
>     files so that packages can just register new actions without much
>     fiddling.
>   + Solves the problem once and for all.
> 
> Obviously (4) is the solution we actually want. I discussed this with
> Michael a bit and it seems that we can even make this efficient by
> adding a kind of "filter" expression to every module that can be
> evaluated quickly, which avoids calling all modules for every received
> event. However, the design of the module, file structure, and filter
> descriptions requires a good deal of thought. It is nothing that one
> person can/should design in two hours on a lazy afternoon, it should
> rather become an extended BoF at the next conference.

I like (4) except for the bit about throwing away update-notifier and
gnome-volume-manager.  I assume we could do this in such a way as to do the
transition in stages, though, yes?

Have you discussed our problem with the GNOME folks (especially the g-v-m
maintainer) to see what they suggest?  There are surely other applications
for such a system.

> Since I don't think that we can implement (4) in a really good way for
> Breezy, my gut feeling is that we should do the Ugly Hack (tm)
> described in (3) for Breezy, and come up with a really good solution
> for Breezy+1.

I think that if we keep (4) very simple, and don't try to transition
existing applications to it, it should be achievable for Breezy.  However,
it is certainly more work than some of the other solutions.

Did you consider having the mixer applet listen for these events?  It would
be nice to have that applet integrated with sound card selection anyway.

-- 
 - mdz

Event types

There are various types of events:

  • time based (periodic or one-shot)
  • hotplug based (a new device was added/removed)
  • syslog based (some critical syslog event)
  • dbus based (some signal was send)
  • crash based (a application has crashed, might be integrated into a dbus msg)
  • file/directory changes (apt was run, a new "hook" file was added)

Architecture

The framework needs to be plugin-based to make the integration of the various sources easy. It should be possible to register plugins in the daemon either as native (compiled in or dlopend) components and as external scripts. Plugins should be able to register "filters" that limit the scope of the events they recieve. To make the system maximum flexible we may consider using lua as a addtional way to write plugins (but that's something controversial becaue it means adding a additional dependency).

Filtering is very importend because event sources like fam/gamin may generate huge amount of events.

Scripts could live in:

/usr/share/event-notifier/hal.d/
/usr/share/event-notifier/log.d/
/var/lib/event-notifier/hooks.d/

etc

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion

See also

InteractiveUpgradeHooks

From unknown Tue May 31 14:05:43 +0100 2005 From: Date: Tue, 31 May 2005 14:05:43 +0100 Subject: Python? Message-ID: <20050531140543+0100@www.ubuntulinux.org>

I think it's a good idea to add some kind of scripting language to write plugins, but instead of using lua one might consider to use Python, because it's allready part of minimal installation and for that reason wouldn't add another dependency.

From TacoWitte Sat Jun 11 19:09:33 +0100 2005 From: Taco Witte Date: Sat, 11 Jun 2005 19:09:33 +0100 Subject: "local nagios" Message-ID: <20050611190933+0100@https://www.ubuntulinux.org>

This idea sounds like a local nagios or something that can be used together with nagios; maybe it's possible to distill a general health status from the information the event notifier framework receives which can be used especially in larger networks.

UbuntuDownUnder/BOFs/EventNotifierFramework (last edited 2008-08-06 16:21:13 by localhost)