[RFC] Msn-prpl refactor
Jorge Villaseñor
salinasv at gmail.com
Wed Jun 2 19:08:38 EDT 2010
As you have seen, I have done some cleanup on the msnp-tlc branch, I
wanted to do this before start rewriting/refactoring stuff. This way I
can get a better idea of how modules interact (or should).
This is a draft idea and want you to review it before start coding it.
(copied to http://developer.pidgin.im/wiki/SlpArchitecture so it can
be updated there)
Almost every data the msn protocol transmit go in form of an SLP
Message and is sent using SLP. There are two available methods to
transmit this data being trough the switchboard and direct connection.
1 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.
1.1 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
1.2 SlpCall
Represent an SLP transaction creating the messages as needed and
managing most of the msg specific management (what to do on each
response).
1.3 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.
1.4 Conn
This modules must expose a common interface so they can be easily
attached to SlpCall and Netwrok interfaces.
2 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.
--
Masca
More information about the Devel
mailing list