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.
