pymsn scenarios

Not a scoop, the MSN address book works using SOAP services. Those services provide methods to manipulate data on the server. However, when you want to do something like block/unblock a contact or synchronize the lists, you have to call several different methods as a sequence. This can be an issue in pymsn since the SOAP calls are asynchronous. Trying to understand what the “partner scenarios” mean, I finally find a solution out.

In the MSN SOAP calls, there’s an header field name “partner scenario”. That field seems to have a different content related to the moment it’s used (when adding a contact, when accepting a contact request…). Even if the server doesn’t seem to discriminate on that field, the new service stack allow us to use the right partner scenario at the right place. For me, partner scenarios are all about the context : it’s not that bad to know in what context a method is used.

So my idea was to create scenarios objects in pymsn. A scenario object handles an action like “block a contact”, to and fro, calling several SOAP methods if needed. Since the calls are asynchronous and we’re using callbacks to know when the response is available, a scenario object defines kind of a “chain of callbacks” that finally ends up calling the scenario callback. A scenario object can be executed, actually it’s very close to the command design pattern.

The high level user won’t manipulate the scenarios : scenarios help us to have a clean address book object which just has to create scenario objects, fill them with the needed data, and execute them.

the new pymsn service stack

Bored of trying to generate the ugly SOAP stuff from the MSN protocol with SOAP python libraries (SOAPpy, ZSI or our very own internal library), we finally came up with a new way to communicate with web services. We are now using massive string formatting! Each SOAP method is described in a ‘description’ file which contains its header and body. On top of that, classes inheriting from a SOAPService class are able to generate the SOAP method calls and the response or error callbacks handle. There is one of these class for each real service. At the top level, the user will for instance only have to care about an AddressBook object that uses the address book (contact management) and sharing (membership management) services and where all the data is normalized. Tough the “massive string formatting” way could sound a bit tricky, we managed to get a clean and flexible enough stack which allows us to do whatever we want without creating a mess. It was sweet to rely on it to build the new address book support to pymsn during GUADEC (more on that later).

SOCKS4 proxy support in gnet

Last weekend, I added support for SOCKS4 proxies in gnet, the networking sublibrary in pymsn. SOCKS4 support was pretty simple to implement since the SOCKS4 protocol is just a quick handshake at the beginning of the connection. Supports for the extension SOCKS4a (used when the application cannot resolve the host IP itself) and SOCKS5 will be added later. SOCKS5 brings several ways of authentication. The goal is to finally implement a smart behavior concerning proxies in pymsn : the application could choose the right way to connect to the host : no proxy, HTTPConnect, SOCKS4, SOCKS4a or SOCKS5.