Brain Storm

This is a preliminary list of ideas, format and elaboration will come next.

• Take as much code as possible from msn.c
• Unify command callback functions maybe doing cmdproc processing incoming commands too.
• Reorganize code in sub-modules.
• Contact list: get cache working.

Roadmap

• Reorganize slp callbacks like sb and ns.

Future Work

• Create a standalone msn.h
• Make msn-prpl.c to just call msn.h functions and initialize prpl struct
• Create a purple-msn interface layer

Proposed Architecture

Architecture

There will be a self contained stack that makes transparent to every other module about the details of SLP and SLP messages. The proposed architecture exposes a single SLP API on top of the stack and pass it to the lower layers as needed: SLP API-> SlpCall? -> SlpLink? -> Network. Where SlpLink? is an abstraction of the possible transaction methods, each defined in the DirectConn? and SBConn modules.

SLP API (WIP)

This API must abstract everything others modules will need from SLP transactions. This will be the one that creates the SlpCall? for any new transaction as needed

SlpCall?

Represent an SLP transaction creating the messages as needed and managing most of the msg specific management (what to do on each response).

SlpLink?

Abstract a Connection. Try DirectConn? and fallback to SBConn if the former fails. This module is also responsible to get the data that must be sent from files or write down the received data.

Conn

This modules must expose a common interface so they can be easily attached to SlpCall? and Netwrok interfaces.

Implementation

• SBConn and DirectConn? can have a conn_ops structure which will be called by the SlpLink? module,
• SBConnmust be extracted from the actual Switchboard module.
• Use an MsnTable? in SlpCall? to manage the SLP protocol callbacks.