EventNotifierFramework
- Created: a long time ago by someone unknown
Priority: NeedsPriority
People: NeedsLead, NeedsSecond
Contributors: MatthewPaulThomas
Interested: MartinPitt, Martin Krafft
Status: UbzSpecification, BrainDump, DistroSpecification
- Branch:
- Malone bug:
- Packages affected:
- Depends:
- Dependents:
- BoF sessions: none yet
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
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)