Add event notification and subscription system

[Mikkel Kamstrup Erlandsen]

Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit over the top, but apps still need a way to get notified of events elsewhere in the system.

This bug relates a lot to bug #447417 "Zeitgeist should have any kind of system to protect users privacy" where a dynamic black listing system is needed. This is sort of inverse to a notification system (only "sort of" mind you).

I want to use this bug as a tracker an reminder for us/me to finish this feature. I have it pretty cut out in my head, so if any one else starts on this please ping me...

[Seif Lotfy (seif)]

I really think this should get into 0.3.0 though! I think Siegfried could
get it up an running in a matter of 2 hours! :)
0.3.1 should reduce new features and be all about extending configurability,
fixing bugs and writing new extensions!

2009/11/26 Mikkel Kamstrup Erlandsen <email address hidden>

> Public bug reported:
>
> Zeitgeist 0.2 relayed all incoming events over the bus. This might be a
> bit over the top, but apps still need a way to get notified of events
> elsewhere in the system.
>
> This bug relates a lot to bug #447417 "Zeitgeist should have any kind of
> system to protect users privacy" where a dynamic black listing system is
> needed. This is sort of inverse to a notification system (only "sort of"
> mind you).
>
> I want to use this bug as a tracker an reminder for us/me to finish this
> feature. I have it pretty cut out in my head, so if any one else starts
> on this please ping me...
>
> ** Affects: zeitgeist
> Importance: High
> Assignee: Mikkel Kamstrup Erlandsen (kamstrup)
> Status: Confirmed
>
> ** Changed in: zeitgeist
> Status: New => Confirmed
>
> ** Changed in: zeitgeist
> Importance: Undecided => High
>
> ** Changed in: zeitgeist
> Assignee: (unassigned) => Mikkel Kamstrup Erlandsen (kamstrup)
>
> ** Changed in: zeitgeist
> Milestone: None => 0.3.1
>
> --
> Add event notification and subscription system
> https://bugs.launchpad.net/bugs/488967
> You received this bug notification because you are subscribed to The
> Zeitgeist Project.
>
> Status in Zeitgeist Framework: Confirmed
>
> Bug description:
> Zeitgeist 0.2 relayed all incoming events over the bus. This might be a bit
> over the top, but apps still need a way to get notified of events elsewhere
> in the system.
>
> This bug relates a lot to bug #447417 "Zeitgeist should have any kind of
> system to protect users privacy" where a dynamic black listing system is
> needed. This is sort of inverse to a notification system (only "sort of"
> mind you).
>
> I want to use this bug as a tracker an reminder for us/me to finish this
> feature. I have it pretty cut out in my head, so if any one else starts on
> this please ping me...
>
>

[Mikkel Kamstrup Erlandsen (kamstrup)]

If we want to re-instate the old system it is a matter of a few lines. But that would be a step back IMHO. And writing a full template based notification system could not be done in two hours by one. It's not a huge task, but definitely more than two hours :-)

Besides, I really think we should stop shoveling features into 0.3.0 and go with a slimmer, more stable release, instead of one packed with features and API we need to change afterwards.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Let me add a comment here on why we can't just emit a signal to everyone...

In the future it is not impossible that many apps are connected to Zeitgeist. Indeed if we have a hook in Gtk+ or Glib then *all* apps are connected to us. Thus we'd send a signal to all desktop processes - waking them up - meaning bad power and CPU usage. Especially on embedded devices and netbooks this could be notable.

[Siegfried Gevatter (rainct)]

Yeah, I agree you way is the way to go (I'm just wondering why the
Tracker guys didn't think of this, as I had a talk with Ivan at
Bolzano and he told me they also have problems with signals and that
their not optimal solution was to send a different signal for every
type of data).

Unrelated to that, I also think I'd be important to have this in 0.3,
as without it Zeitgeist can't power any proper interface (eg. forget
about 0.3 being useful for Activity Journal, Shell or anything else).
So even if this means delaying the release a couple of days we can
accept this given the importance of the feature.

[Mikkel Kamstrup Erlandsen (kamstrup)]

I think I read somewhere in the Tracker changelogs that they committed a fix for this, but maybe I mistook a normal comment on the matter as a real committed fix...

Regarding 0.3 status I think we should ship 0.3.0 without it. There's nothing stopping us having 0.3.1 next week already of we have good features and fixes lined up. It's just to make sure that we in fact get *something* out there. We are in danger of ending in perpetual-feature-creep lan otherwise...

As I also stated to Seif I'd rather delay this a bit until we've figured out a good API, than ship something we have to change shortly after.

[Mikkel Kamstrup Erlandsen (kamstrup)]

I am looking into the directed signals approach, and from a look at the DBus spec this should be possible. If we can somehow create our own dbus.lowlevel.SignalMessage then we can call set_destination(unique_name) on that. See http://dbus.freedesktop.org/doc/dbus-python/api/. Alse see http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-messages.

Nothing concrete yet - just a heads up.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Ok. I think I know how to do this now. I just need to find the time to actually write the code :-)

Look at the nested emit_signal() method here: http://dbus.freedesktop.org/doc/dbus-python/api/dbus.decorators-pysrc.html#signal

[Markus Korn (thekorn)]

In the attached branch I tried to put together a sample dbus service which *should* send directed signals, but somehow it is not working as I expect it to work.

There are two scripts, service.py which starts the service, and client.py (0|1), the client. starting the client with argument '1' means 'subscribe to signal', '0' means 'don't do this. If the client should listen for the signal, it subscribes to the "Hello" signal after 2 seconds for 10 seconds, and then unsubscribes again.

But as you might find out when you start two clients (one which is subscribed to the signal, and the other one is not) both clients receive the signal :(

On the other hand when you change the set_destination statement in service.py (~line 123) to some random bus name it works as expected, no connected client, no matter if subscribed or not receives the signal.

[Markus Korn (thekorn)]

maybe this screencasts help to understand whyt I mean ;)

[Mikkel Kamstrup Erlandsen (kamstrup)]

Cool that you did this test Markus! I am a bit troubled by the results though...

I fear that signals are by definition always broadcasted. We may be able to work around this by setting a match rule on each signal connection on the client side, but I am not sure... Something like adding a named param. destination=bus.get_unique_name() to the line where we call object.connect_to_signal() in client.py. However it does not appear to be possible according to http://dbus.freedesktop.org/doc/dbus-python/api/dbus.proxies.ProxyObject-class.html#connect_to_signal.

The alternative is to do our own simple monitoring system... Maybe adding two methods to the Log interface:

InstallMonitor(in o client_monitor_path, in E event_template)
RemoveMonitor(in o client_monitor_path)

And then defining a new interface org.gnome.zeitgeist.Monitor with a single method

Notify(in aE new_events)

The way we'd do this in the engine is to remember the unique bus name of the caller in InstallMonitor() and then ping back on that address and object path client_monitor_path, on the interface org.gnome.zeitgeist.Monitor. We'd automagically drop monitors when clients disconnect by listening for NameOwnerChanged.

Somehow I am nore inclined to the Monitor-solution... At least we can be sure that it will always work disregarding if the client remembers to set up the right match rules...

[Seif Lotfy (seif)]

just my piece of non techi view to this issue
we should make sure that it gets in with the 0.3.1 release since teamgeist also depends on it.
Sorry for being absent now my lil brother is over

[Mikkel Kamstrup Erlandsen (kamstrup)]

I have te beginings of an implementation along the lines I describe above. It is still not ready for review, but I have it on lp:~kamstrup/zeitgeist/notification.