Attending XMPP Summit and FOSDEM, 5th-8th of February in Brussels

For the third year in a row, I’ll be flying to Brussels, Belgium next month to attend the XMPP Summit/FOSDEM combo. I didn’t look through the FOSDEM schedule yet but when it comes to XMPP, I’m looking forward to some discussions on Jingle Nodes and Publish-Subscribe. I’ve been working more and more with XMPP in the past months, especially hacking on ejabberd, and attending is a good motivation to get some of my Jingle Nodes related code shaped up on time. See you there!

Where People fits in GNOME

Right after our GUADEC presentation, Ali Sabil and I met with Owen Taylor, Marina Zhurakhinskaya (both from Red Hat’s Online Desktop project), Robert McQueen (Telepathy) and Travis Reitter (Soylent). The goal of that quick meeting was to define how to integrate all those pieces of technologies together. Even if People aims to define a data model and a D-Bus API to be used on all the free desktops, we are also part of the GNOME community, thus particularly eager to see People integration with GNOME technologies happening.

It’s been always difficult to make people understand what People is. Moreover, our project is quite unknown. We are not present on GNOME’s main communication channel (Planet GNOME) and that’s something you feel also at GUADEC when the conference room isn’t very populated. In that blog post, I’ll try to explain what is People and what it will be for GNOME.

The best explanation I can give to begin with is maybe that People is actually like “libsoylent”, which has been announced few time ago. The main goal is the same: provide first-class people objects to applications. Our approach is different: we designed People from the backend to application level, which allows us to consider whatever contact source, while libsoylent, based on what is done in Soylent, only uses Evolution Data Server and Telepathy as sources (for now). I think that our development is more advanced and our solution wider, hence even Soylent should use People.

On the next diagram, you can find several components that are part of the GNOME ecosystem. It is based on the GUADEC after-talk meeting result and is not meant to be exhaustive.

• Green boxes are what we call contact sources. Any application, service or data source handling and exposing objects referred as contacts, friends, persons, people is a potential contact source. Those contact sources are plugged into the People framework through a backend system. That interaction is represented as dashed arrows on the diagram. Each contact source provides partial information about some contacts to People.
• The blue box is the framework. It contains the backend system, a mechanism to gather partial contact informations into high level contact object (often called meta-contacts) and a D-Bus daemon to expose those high level contacts to applications. At some point, we’d also like to expose backend directly to allow synchronization solutions to use them.
• Yellow boxes are a few possible applications that could use the framework.

People in GNOME

Concerning Empathy, the current contact list could be turned into a people list, where each item wouldn’t be an instant messaging contact anymore but just a known person, that you may reach using instant messaging. That list would contain some friends you have in Facebook and you could actually subscribe to them on Jabber directly from Empathy, as People would provide to Empathy the information saying that your friend has a jabber account.

This is what People does, it provides contact information to application, and then applications should know how to use that information. People won’t tell you to launch Evolution to write an e-mail, it’ll just tell you that you can reach a certain contact through e-mail. We then need sort of an “activity launcher” and I think that’s what Soylent should be. Using the people list provided by the Empathy widget set, Soylent should allow you to start activities with the people you know. At some point, maybe Empathy’s client and Soylent are meant to be the same application.

Our demonstration at GUADEC was an application containing a list of high level contacts built from local (sqlite database) and distant sources (lastfm and friendfeed web services). The list exposed contact information such as the full name of the contact, a picture, an e-mail address, a phone number, an icon per social network he’s susbscribed to, all those information being provided by People. At some point, Ali brought his mobile phone next to the laptop and his phone’s addressbook automatically became a contact source (over bluetooth) for the application, adding contacts from the phone in the list. This was supposed to show how flexible the backend system is and how cool are the things that People enables .

Yesterday we set up www.people-project.org which is currently a wiki that will be useful to collaborate on stuff that are not code. We are also releasing 0.0.5 “Smelly hotel lobby” (tribute to our hotel in Istanbul, where people still smoke in public places and People don’t) today, as dictated by our sprint schedule. We are currently developing more backends (Online Desktop, Telepathy, EDS, …) and trying to improve what we have for now. The backlog is huge but considering all the possible cool applications, will is around.

People: a contact management framework

Today, people subscribe to social networks, use instant messaging, subscribe to podcasts and blog feeds, use electronic mail, and communication devices to exchange information but more importantly to keep in contact with their contacts and their entourage. Tomorrow people may use different means to achieve this same goal, but in the end it will always be about contacting people, and maybe by then smarter solutions would be found. But in the mean time, we are are stuck with the proliferation of independent and disconnected applications and appliances, each one tearing unique logical entities away to make them fit into limited models. In simpler words, the way applications treat contacts brings a bad user experience.

Unfortunately, we cannot really do much about it, but we can still try to attenuate the effects on the Free Desktop by providing a unified vision of who is a person to the user. The solution we propose is named “People“.

Many people agree that, in the desktop, a “people framework” is needed. Things get more complicated when it comes to define the scope of it. The People project intends to provide an unified way to access and manipulate contacts for the desktop applications. The goal is not, at first, to gather the pieces and simulate unity, but more to bring the tools allowing to do it in a smart way, among other things. In People, we consider that each contact source is incomplete and provides just a restricted vision on contacts (the way they are represented and the way we can act on them). With that vision, contact sources can be as numerous and lightweight as needed to cover every place where the notion of person appears: LDAP, Google Contacts, Facebook, MIT Public Key Server, Telepathy, EDS, phone address book…

Among the possible top level components that People aim to bring, a service providing meta-contacts (gathering all the little pieces of contacts and bringing back the notion of unique persons) is fundamental, as well as a synchronization solution (to update or enhance whatever contact source from another one). Another idea would be to provide a service managing ephemeral contact-related information (like the presence status of a person) to be shared among applications. An obvious and really great use of People would be an address book management application.

The idea behind the People Project is people sanity for the desktop: when some start to talk about amazing people integration in GNOME, the first step is to get consistency around the notion of a person. As the semantic of a person can’t be defined as a standard, we have to allow and exploit all the possible representations of it.

There are tons of possible applications to be explored: meta-contacts in Empathy, Gimmie or Soylent, integration with Seahorse, personal presence handling, activity framework, contact relationships, multiplayer games… People also fits the definition of what the address book component should be in the Online Desktop.

People is architectured around two libraries: a low level one to build backends and a higher one on top of which will lay a D-Bus interface. That interface must not be tainted by People as other implementations could come up. The libraries are developed using the Vala programming language. We want to allow backends to implement custom interfaces when it makes sense so we are not heading to a less common denominator syndrome. As an example, a relationship interface could be implemented by backends supporting FOAF. We have neat feature ideas that we take care to bring with several hot spots in mind, amongst which stand memory usage, network bandwidth usage (use on mobile devices) and i18n (name representation, automatic phone number formatting, …).

The idea that gave birth to People came up during a discussion I had one year ago with Felipe Contreras. It took some time for us to realize the potential of it. Few months ago, Ali Sabil got interested and passed it as a university project to get some time to hack on it, which brought some helpful hands as well. Lately, the development of People has been more and more active. We are constantly questioning our work in an iterative process to get the better implementation we can provide and each added feature is tested. Our effort aims to provide a working and validating implementation as soon as possible (with the release of a first usable version by June). There is currently a resource request for the People project at Freedesktop.org.

We hope to give a talk at GUADEC to get more people interested!

pymsn, butterfly and empathy

This weekend, Ali got his msnp2p stack polished so we could work on some p2p integration in pymsn. This led display pictures (aka avatars) to land into the library. That means we are really close to release the new version of pymsn on which we’re working for several months now.

Today, as we were implementing display pictures in pymsn, I wrote the telepathy-butterfly (the MSN connection manager for Telepathy based on pymsn) part for avatars, which was a good opportunity to test the new feature. This closes the list of features to implement into butterfly before a release as well, since I got groups and aliasing (you can nickname your buddies) working in the past days. Contact handles format was changed to support Yahoo contacts in butterfly (as pymsn, covering MSNP15, allows it).I’ve tried to integrate the pymsn offline messages feature into butterfly but I wasn’t pleased with it so it’s sleeping in a separate branch for now. However, I’d like to get full membership groups management too to be able to add/remove contacts, block them, etc.

The next screenshot shows empathy displaying my personal MSN account using telepathy-butterfly. I’m really glad that we are finally getting concrete things to show

an OpenIM proposal

I finally wrote a freedesktop.org project request for the OpenIM thing that Ali and I (and certainly lots of other people involved in IM protocols reverse engineering) would like to see come up. The request is a bug report on freedesktop bugzilla, please bring your observations and ideas! Here is quoted the text of the proposal :

This is about a new project that I would like to see come up under the fd.o banner.

I’m part of the pymsn project. Our goal is to provide a full implementation of the latest MSN Messenger protocol for interoperability purpose. So far the project is kind of hosted by Telepathy since it’s the base library for telepathy-butterfly but this is clearly not the place where it should be.

Based on that observation, we would like to build an OpenIM initiative. Such a project would aim to the gathering of people working on the opening of closed instant messaging protocols.

One of the most important goal in this would to have centralized shared documentation on protocols and a clear follow up of features implemented in each project.

Activity around the pymsn project

I begin to hear about some projects using our beloved python MSN Messenger library : pymsn. As you could have guessed, most of them are clients.  There is CupsAndString, a command line client written in 128 lines of python by Alsuren, LiMSN which has a wxWidgets interface and finally Open Live Messenger, a GTK+ client written by Julien Enche (Trapamoosch). Thanks to all of the client developers for your feedbacks and for providing examples of how to use the library .

Of course, pymsn is also the base library for the telepathy-butterfly Telepathy connection manager. There is a development version of butterfly but most of the pymsn new/refreshed features will be integrated in it just before the release because it’s not a weighty work to do and all development efforts should better go for pymsn.

If any reader of this post is interested in learning more on the pymsn project, feel free to join #pymsn on freenode to have a good chat. Contributors of all sorts (developers, testers, documentation writers, …) are welcome too

pymsn article : the crack-powered address book

This article attempts to provide an overview of the contact management system shipped with the pymsn library. In the following I assume you are already familiar with the basic pymsn API that allows you to connect to the server and attach the various event handlers.

Contact management is handled by the AddressBook object which manipulates AddressBookStorage, PendingContact, Group and Contact objects. I will try to describe each of these objects API and related event interfaces.

When you develop a client using pymsn, you generally start by instanciatiating the Client class, and then instanciating the event handlers you created. The Client instance holds an instance of the AddressBook that can be accessed through the address_book property:

client.address_book

The AddressBook instance provides a set of methods allowing you to interact with you address book stored remotely on the MSN servers, in fact each method call result in one or more SOAP requests (ouch). The results of those actions are then reflected on pymsn internal representation of data and the related methods from the AddressBookEventInterface are called to notify you that the changes have been done (contact added, group deleted, …). So all you have to do is to inherit from that event interface and fill the methods with your own needs then instanciate your instance.

Now let’s have a closer look on all those entities…

AddressBook

The AddressBook is the central object in contact management. It owns four important properties :

• contacts is an AddressBookStorage instance. It’s a collection containing Contact objects (actually representing the address book contact list). This object is very useful to request a subset of specific contacts using chained method calls.
• state is an AddressBookState value which describes the synchronization state of the address book. The address book is said to be synchronized when the local AddressBook data reflects excactly what’s stored on the server. When using the Client class, the given AddressBook instance is automatically synchronized at startup (else you would have to call the sync method).
• groups is a dictionary of Group objects indexed by their ids. It contains all the groups that are defined for that address book.
• pending_contacts is a set of PendingContact. Those objects are simple ones containing information on the contacts that asked to be added to the address book. Those pending invitations are to be accepted or declined.

API description

The API is short, simple, and method actions are self explained by their name and the name of their parameters, however when can here explain some bloody details.

Invitations

accept_contact_invitation(self, pending_contact, add_to_contact_list=True)

Method used to accept a pending invitation. It takes a PendingContact object from the pending_contacts set. You can specify if you want to add the new contact to your contact list (default behavior) or not. The pending contact will then be automatically removed from pending_contacts.

decline_contact_invitation(self, pending_contact)

Method used to decline a pending invitation. It takes a PendingContact object from the pending_contacts set. The contact will be blocked and won’t appear in you contact list. The pending contact will then be automatically removed from pending_contacts.

Contacts

add_messenger_contact(self, account, invite_display_name='', invite_message='')

Method used to add a “messenger contact” to the contact list. The “messenger contact” means a MSN or Yahoo contact (as opposed to “mail” or “mobile” contacts which are pending soon-to-be-added pymsn features). The main argument given to this method is the account (a valid email address). Giving a Yahoo domain email address, pymsn will try to add it both as a MSN account and a Yahoo account. You can also specify a display name and a message that may be displayed by the client used by the contact receiving the invitation.

delete_contact(self, contact)

Method used to delete a contact from the contact list. The given argument must be a Contact object from the contacts collection. The contact will then be automatically removed from contacts.

block_contact(self, contact)

Method used to block a contact. The given argument must be a Contact object from the contacts collection.

unblock_contact(self, contact)

Method used to unblock a contact. The given argument must be a Contact object from the contacts collection.

Groups

add_group(self, group_name)

Method used to add a group to the address book.

delete_group(self, group)

Method used to delete a group from the address book. The given argument must be a Group object from the groups dictionary.

rename_group(self, group, new_name)

Method used to rename a group. The first argument must be a Group object from the groups dictionary. The second one is a string.

add_contact_to_group(self, group, contact)

Method used to add a contact to a group. The first argument must be a Group object from the groups dictionary. The second one must be a Contact object from the contacts collection.

delete_contact_from_group(self, group, contact)

Method used to delete a contact from a group. The first argument must be a Group object from the groups dictionary. The second one must be a Contact object from the contacts collection.

AddressBookStorage

An AddressBookStorage is a set that contains Contact objects. This storage object provides several way to request for contacts. Queries are method calls that can be separated in two families : method beginning with “search_by” return sub address books (which are AddressBookStorage too) based on a field selection and method beginning with “group_by” group contacts together in a dictionary, based on a field value. The class provides some methods to query on not trivial Contact attributes :

search_by_memberships(self, memberships)

This method returns an AddressBookStorage object that contains the Contact objects which match the given memberships parameter. That parameter is a bitwise OR of Membership lists. There are lists for blocked contacts, allowed contacts, contacts that got you in their contact list, etc.

search_by_groups(self, *groups)

This method returns an AddressBookStorage object that contains the Contact objects which are part of the given groups. Each group parameter must be a Group instance.

group_by_group(self)

This method returns a dictionary in which each key is a Group and its linked data an AddressBookStorage object containing the Contact objects which are part of the key group.

In addition, pymsn makes use of the python __getattr__ method to provide custom query methods. Those are based on the next two methods that perform queries on the Contact object attributes :

search_by(self, field, value)

This method returns an AddressBookStorage containing the Contact objects for which the field attribute matched the given value.

group_by(self, field)

This method returns a dictionary which associates values of field to the related Contact objects.

Since the “search_by” methods return AddressBookStorage objects, you can execute complex request chaining method calls. For instance, the next instruction will select all the Yahoo Messenger contacts from the address book and then group them in a dictionary using their presence as keys :

address_book.contacts.search_by_network_id(pymsn.profile.NetworkID.EXTERNAL).group_by_presence()

Contact, PendingContact and Group

Those objects are the ones manipulated by the address book but the best thing to do is to refer to the API documentation to learn more about them so they won’t be described here.

AddressBookEventInterface

As with the other pymsn event interfaces, you’ll have to implement that interface and attach it to the Client. We won’t describe each method of the interface : almost each of the AddressBook methods fires an event method when its task is accomplished (the given arguments are then the concerned Contact or Group objects). We can however note that an event method exist to acknowledge you when there’s a new pending contact and that the errors that could occur performing the task (for instance when trying to add a contact who is already in the address book) are redirected to the client error handler.

Conclusion

Pymsn provides a powerful contact management through the address book. The API is still young and could certainly be improved : feel free to submit patched or bug reports. Feature requests are welcome too, we already have some pending ideas to be implemented : contact informations update (concerning mail addresses, birthdate and that kind of stuff), possibility to automatically add a contact to groups when adding him to the address book, etc.

If anybody find it useful, that blog post will become a page somewhere and will be updated to each API change.

Status of pymsn services development

Here we are :

• Implementation of the address book is finished : the integration in msnp and the rest of pymsn happened last weekend. We are now massively debugging the behaviors of the service thanks to the help of Julien Enche (Trapamoosch) who is developing a client, daily integrating each of our feature adds, thus detecting lots of bugs. Thanks again Julien for your assiduity to post bug reports.
• Implementation of the content roaming service is finished : this is fresh from tonight but all my tests went good. We are now able to retrieve the display name, personal message and display picture stored on the server as well as we can publish those. We now need to find a way to properly integrate this within the client stuff.
• Implementation of the offline messages service is close to be finished : we’re able to get the message headers and fetch their content. The method used to send messages is the only thing missing for now but that’s just a matter of time since there’s no difficulty around. Little work on integration with the rest of the library is still to be done.

Future : it seems that concerning services, we’re closer to the end than ever. Anyway, there’s a huge thing missing for now : Spaces. That service is the last existing. It allows to user to interact with all the blogging stuff in the MSN/Live network. Supporting spaces would be a great plus for clients. So we’re gonna start to work on this. Nothing is done yet and there’s a lot of reverse engineering effort needed. [Update : more on this in Youness's comment]

Now a screenshot taken from the excellent Baobab, a disk usage analyzer, concerning the library directory from the rewrite :

We easily figure out that the service package represents about 56% of the whole library. This is due to the huge amount of lines of code we have to write to set a new service up. We can be glad with our SOAP stack since we now can generate anything we want in a clean enough way but services aren’t a fun part to work on : once the reverse engineering is done, you just have to follow the rules, fit the design, and you finally get your stuff working. I hope I’ll be able to contribute more on other parts of the library soon.

filling the pymsn AddressBook

This weekend, I’ve started to implement methods as add_contact, delete_contact, add_group, delete_group, rename_group, etc. at the pymsn’s AddressBook level of abstraction. Things are getting cleaner and with hope, almost all of the soap stuff in WLM will be covered in pymsn in the next three weeks. Changes are merged on my personal branch.
Last week of school before holidays, I’m totally out of classes and I should get myself back into all the school stuff because it could hurt later with exams (at the end of May). I’m not really motivated to code on simmobil too. I’m going to Paris on the first week of holidays (Tuesday-Friday), attending Fostel and sleeping by my brother. I’ll maybe give a lightning talk at Fostel about pymsn (need, development, use) but I’m not really sure yet : first talk in english in front of skilled people, it could hurt : I need to prepare for it and we’ll see. The other week will be filled with school and pymsn work. Adrien should start working on halazoon soon, maybe we’ll work on the architecture this week so he could start coding. Since it’s based on telepathy-python, it’s not gonna be difficult. I have a urge need to play with cairo too

Well, trying hard to read my network course book…

Plans

No time to say anything but that enumeration :

• Mar 15-18 CeBIT, Hannover : 18 hours in the bus (I take a copy of telepathy spec + Asimov’s Foundation with me), bier, friends, food, technologies ;
• In two weeks, holiday again (two weeks long) : massive work on pymsn, foundations of halazoon, and Apr 4-5 Fostel, Paris with maybe a lightning talk about pymsn/halazoon ;
• May 10th-13th Rock n’ Solex, Rennes : concerts and solex race ;
• Summer : 3 months holiday, I plan to work a bit (like, a month) where I usually work at summer to earn money to feel comfortable to realize all of my others summer projects : July 15-21 GUADEC, Birmingham where we (the ospy/pymsn/butterfly/halazoon team) plan to give a talk. I’m looking forward to see Ali and meet Ole. August 10-12 La Route du Rock, St. Malo. I plan to spend several weeks in Olso, Norway. All that surrounded and mixed by full time development on pymsn ;
• Back to school October 1st.