Monday, 19 March 2012

Facebook provider for GNOME Online Accounts

Following Xavier's steps, last week a new patch set has been commited to GNOME Online Account master repo, this time to add support for Facebook client-side auth flow, which does not require secret keys to work.

This means that since GNOME 3.4 it will be possible to enable Facebook support at configure time (yep, by default it's still disabled. Distributions will explicitly need to enable it for now). Currently only chat is supported.

The steps to enable it are easy:
Use --enable-facebook at configure time and compile+install as usual.A default FB application id is used, so you don't need to provide it.
Using the freshly updated goa-daemon (use --replace in case you're unsure) select online accounts from the control panel, add a facebook account (which should be now possible to select, along with at Google and Windows live if you've enabled it) and follow the on-screen instruction.
You'll need to authenticate yourself against Facebook and authorize the GNOME application.
Once your account has been created, set your presence to Available using Empathy or gnome-shell.
Now chat with your Facebook buddies \o/

It requires empathy (>=3.3.2), telepathy-gabble (>= 0.15.0) and of course gnome-online-accounts (the soon soon to be released 3.4.0, or directly git master)

Thanks to Xavier who backported to 3.4 my patches, originally meant for 3.6, and to Collabora who allowed us to improve Gnome Online Accounts!

Wednesday, 1 February 2012

Learning Natural Interaction

Just to say it out loud in the hope someone else is interested in it:

I've been studying and I'm intentioned to write an open sourced Natural Interaction module for OpenNI or libfreenect which is able to do skeleton and gesture recognition.

Ideally and in the *very* long term I'd like to have something very close in functionalities to what the closed sourced NITE is for OpenNI, but to begin with a simple shape or movement recognition module will make me happy.

I don't know anything about the subject, including the basic of image manipulation, but if someone would like to have some fun thinking about it, let's join the forces!

Friday, 22 July 2011

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=",".
Imagine several clients using this rule to listen to, but 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.

Wednesday, 20 July 2011

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 :)

Creative Commons License

Just some notes about the Net by Cosimo Alfarano is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Italy License.
Permissions beyond the scope of this license may be available at