Ubuntu Wiki

This specification is with regards to the planning and implementation of the Geyser project as a whole. It is intended as an introduction and will be split into seperate sections at a later stage.

Though there are many other notification frameworks out there, Geyser claims to be different, why wouldn't it. The Geyser project works around the idea of plugins; input, output and filters. You may like to think of this as a stream of data eminating from it's source, the input plugin, passing through filters, and ending up at the output plugin. It is using this system of configurations of plugins that Geyser should be an ultra generic platform for notification generation.

Features to be included/designed/approved

• Auto updating of plugins
• Multiple inputs mapping to multiple outputs
• Filters for data passing through Geyser, ie, notification contains X
• Full logging of all notification data
• Support for native and non-python plugins over dbus
• Support for TCP/IP connection inputs through dbus daemons
• Highly abstracted API for creating plugins to remove as much of the complex stuff from the user as possible
• Support for integration into standard desktop apps through core plugins, as well as integration with other notification frameworks

Implementation

Geyser will at it's core run the Geyser daemon. This is a multiuser, multiplugin, dbus enabled, threaded system. Here is how it is expected to work, losely. This is still under discussion and development.

• Daemon Started
• Configuration for each notification read and processed as follows
  • Notification Class (NC) instantiated
    • Input Plugins (IP) added to NC
    • IP configured
    • If an IP is external, the external daemon is started, if it needs to be, and a dbus connection is readied
    • Filters are created and linked to IPs
    • Output Plugins (OP) added to NC
    • OP configured
    • If an OP is external, the external daemon is started, if it needs to be, and a dbus connection is readied
    • Filters connected to OPs
• Input notification triggers, if external, a dbus message is sent to the dbus IP, either way, the result is the same.
  • Gobject signal is emitted and picked up by the NC
  • Notification is logged
  • Message is passed through the filters
  • GObject signal emitted and picked up by the OP

This is a very very loose definition of how the system will work. As the input plugin and output plugins will both be able to query the log. This will be defined better in the API section.

Use Cases

• John want's to be notified everytime someone adds a file to an important directory. He uses Geyser to watch the directory with an input plugin and sets the output plugin to send him an SMS message
• Kairi want's to monitor changes to her launchpads team repository and for it to log the changes and mail her. She sets up a VCS input and uses two output plugins to send her mail and log the changes. She also realises she needs to do this to several repositories. So she uses the favourite option in Geyser to save her template her settings for the output plugins so she doesn't have to waste time setting them up over and over again. Later her notification email address changes, she changes it once in the template and all plugins are updated.
• Simon wants to link his third party app up to Geyser. It's written in C, and so he uses the Geyser dbus input plugin to communicate with. He also wants the output to goto a different third party notification app, and so uses Geysers dbus output plugin to achieve the same thing.

API

Input Plugin
getName()
start()
pause()
stop()
setupConfig()
emitSignal()

Message:
humanReadable -> String
info -> data
type -> string (mime-type of info)
sender
hasExtendedInfo -> Boolean
getExtendedInfo -> data (Used for possibly-expensive extra info about the event)
extendedInfoType -> string (mime-type)

Comments

• MatthewPaulThomas: I suggest starting with use cases. What are some examples of things this will let me do that I can't do with Ubuntu now? What will I see/hear?