D-Bus eavesdroppers and unicast signals

There was an interesting issue in D-Bus, related to unicast vs broadcast signals, which led [edit: typo] to a small change in specs and which might be of some interest for D-Bus developers.

Unicast signals are not widely known and probably even less used, but they are possible.
They are useful, for instance, when you need to trigger an action from a single client, among your listeners.

Until some days ago, when a unicast signal was emitted, it was actually received by everyone listening to the signal's interface (unless a strict rule was added, unusual), waking up a number of processes which actually weren't interested in the signal.
Collateral effect, waking up cost apart: those processes might actually consider the signal as they were the actual recipient and take some action upon it. Bad.

Typical rule having this problem is "sender="org.foo,interface=org.bar".
Imagine several clients using this rule to listen to org.foo, but org.foo wanting to send a signal to :1.23 only.
Specifying destination=:1.23 for the signal object didn't really work since no dest=val was specified in the rule, allowing any destination actually matching it and all the listeners to be woken up anyway.

The problem with this situation was fixing the bad behaviour without filter out eavesdroppers, which actually wanted to receive the message even if not for them.

The solution is a sort of "eavesdrop opt-in", as Thiago proposed to add a keyword to DBusMatchRule, "eavesdrop=true|false" which defaults to false and with which the listener declares that it really wants to eavesdrop, enabling it to receive messages (including signals) not meant for it (AKA eavesdropping).
Otherwise any message (again, including signals) with a specified destination won't match a filter with no or different destination. Also a rule with a specific destination won't match broadcast messages.


In other words, by default a match rule filter will match only broadcast messages or the ones specifically for you, unless you declare your very nature of eavesdropper by adding "eavesdrop=true" to your filter rule.

This is a behavioural change and consequently means a small amend to the D-Bus spec for 1.5.x.

It also means that if you maintain some code which acts as an eavesdropper, you should fix the code adding "eavesdrop=true" to your filter.
Note that it's only for 1.5.x branch; adding the "eavesdrop" keyword to a filter sent to a 1.4.x bus will fail as the keyword is not recognized.
An example on how to deal with this change keeping compatibility toward 1.4.x (stable branch) and 1.5.x (devel branch) at the same time is shown by this bustle fix. It checks for the feature presence and prepends the keyword if supported.

Facebook, Google+ and Diaspora (part 2)

This probable is more a tweet [Edit: typo.Thanks to Robot101 :D] than a blog article, but since my last post was about the same subject, I felt it'd make sense to point this article out.

Its author analysed in a deeper way than what I did what the future looks (or is?) like and, I have to say, that after a bit of time spent on G+, I envisioned pretty much a similar future, reason for which I started following Edd Dumbill on G+ and of Twitter ;)
Also thanks to Zack for mentioning the article.

End of post, I said it was short, didn't I? ... and I made it longer than what originally conceived :)

Facebook, Google+ and Diaspora

Google+ opened to the small public some days ago, I'm not really going to comment anything about it for now.

The purpose of my post is actually reminding people of another interesting project, Diaspora, which actually fits several of my views over social networking.

I really hope that when Google will release API for its G+, there will be some chance for Diaspora to integrate with it and, most important, an opening for G+ to operate with Diaspora.

Most of us use(d) Facebook, now almost any geek I know is joining G+, some of them rejoicing its advent as an opportunity to leave Facebook for good.
That's not really my intention and I don't think it's the point of the whole social thing.

What about, instead, allowing the whole social sites to inter-communicate, exchanging information and letting users being able to see each other independently of the platform used?

That's clearly not possible so far :-), but it is the reason for which years and years ago (Internet-time rules apply) I got interested in FOAF, last year I crossed my fingers with Diaspora and now I'm doing the same about Google receiving some enlightenment bit and getting the right path about profile sharing.

I'm aware that Google point is to re-factor the whole Google experience around Google Accounts and the profiles associated with them, and the major point of it is making G+ a bigger part of G profiles (if you are a Google Profile user, you'll probably noticed that your profile is now your public view of G+, with your public posts for instance).

My point is: Google is aware that not everyone agrees with Google wanting to extract information from your profile, your habits, etc and some of us is not really using Google 100% for this reason.

Also, Google started the Data Liberation front, so why not taking the next step and allowing people to inter-operate with other open [1] social sites?

The big part of the work is not helping Diaspora evolving and gaining power, IMHO, but pretty much the other way round: helping the idea of inter-communication to be a central point of the social experience: this idea getting stuck in some important and enlightened mind so that a bridge will be offered.

But I'm just a noob in the subject: it's just a foolish idea that has been in my mind for long enough and I needed to express :-D

OpenNI in Debian

The world of augmented reality is quite fashinating.

I recently got interested into Natural Interaction due to the popularity of  Microsoft's Kinect and decided to package OpenNI for Debian.

OpenNI is a framework aiming to making natural interaction transparent to the user/developer, publishing a unified API and abstracting the access to different sensors and modules. Currently it supports some Asus sensors and there is a branch on github supporting also Kinect (which is the one we're packaging).

Some cool projects are already using OpenNI: ROS, PointClouds and OpenCV come to my mind immediately.

We'are working on OpenNI package in the Multimedia Maintainers group on Alioth, the package is still not ready to be uploaded to unstable and upstream has some major problems like the lack of SONAME in its produced library, so some communication with upstream is needed but for preliminary use the packages are in a decent state: OpenNI, PrimeSense Sensor, NITE (non-free).

NITE is a closed source module set for advanced body and scene recognition, unfortunately PrimeSense didn't opensource them, thus I decided to use the same approach of flashplugin-nonfree and write a downloader.

For the sake of completeness, unstable already has libfreenect which purpose is similar but specifically oriented to Kinect.

I am studying both and really hope that in the next future some open source project will make (at least) skeleton and hand recognition available under an open license. People are already working on it, according to Google.