libkmess-msn Design

This page details the structure of the libkmess-msn library, including all interfaces, classes, arguments, signals and slots. This page is designed to be a reference point for the design of the library. General discussion and ideas about the library should go on the forum - what goes in here should be the agreed upon details.

UML Diagram

 This thread contains a draft of the methods, properties, slots and signals for all parts of the library. It's not complete yet, there have been some suggestions. When the draft is done, it will be made public here.

Namespaces and Naming conventions

All library types will be bundled under the "KMess" namespace. This allows us a little "branding" but also prevents any symbol clashes.

Class names will be prefixed with "Msn". Example: MsnContactList, MsnConversation, etc. This serves to identify these classes as belonging to the MSN protocol. The names shown here are all temporary and subject to change, they're here only to exemplify their meaning.

Methods will be named after Qt's style: setters will be setSomething(), getters something(), without any "get".

Library components

* Contact List model *

The Contact List will be kept hidden, and a QAbstractItemModel representation of it will be exposed for the GUI to use.

* Conversations *

The MsnConversation class will be the only interface with which the GUI will have to talk to handle chats.

Chat messages

Chat messages will be implemented with a Message base class. It will offer basic getter methods, sender(), isIncoming(), type(), etc. Every message type will be implemented as a subclass of it: TextMessage, InkMessage, etc. A raw Message* can be casted according to its final type using type(). The chat() call will return a pointer to the parent MsnChat.

Chat message acknowledgements

On Live Messenger switchboard connections, we can send along with our message whether we want an acknowledgment of success or a failure message, or nothing. The library will, by default, ask for acknowledgments (ACK's) and delivery failures (NAK's) and emit signals when they are received. Applications can connect to those signals to show their specific behavior. The Message class and its subclasses can disable this behavior with setMessageConfirmation().

Sending and receiving chat messages

There will be a single slot method to call to send messages, some sendMessage(Message*).
There are two signals for transferred messages:

• transferredMessage(Message*) will be emitted whenever *anyone* has sent a message: the user; the user on another location; a contact; another part of the library; the GUI. Having one signal emitted by every message being appended to a chat, will make it easier for applications to have consequent code flow for displaying those messages.
• receivedMessage(Message*) will be emitted whenever someone (but not the user though) has sent a message.

* Peer-to-Peer Stack *

We are waiting for Gregg to send us (in the next week or so) his implementation of the p2p stack. It is not the new implementation he said he's rewriting, but an update to his old one (the one he originally shown us), but the apis will be compatible so no problems. We'll wait for that.

Display picture transfers

Whatever the medium used for the DP transfer (DC or SB or smoke signals) MsnObjects will be hidden from the GUI, and only some signals will be available: ourDisplayPictureUpdated(), failedOurDisplayPictureUpdate(), theirDisplayPictureUpdated(), failedTheirDisplayPictureUpdate(). A method to set the user's own DP will be available too.

Webcam transfers

A really quick way to allow a flow of frames to go from the lib to the GUI and vice versa is passing a reference to a QLabel or QImage, which then the code responsible for drawing will fill.

Using isf-qt and libmimic-qt

isf-qt and libmimic-qt are not hard dependencies of libkmess-msn. If they are available webcam and ink support will be available, if they are not then the appropriate API calls will be stubbed out or unavailable.

As this idea is fleshed out this section will provide more detail.

Samples

Miscellaneous things we've agreed on

• The GUI should ask to add a contact by calling a library method (say, addContact()) with just the handle and optionally the groups where to add it. Asynchronously, the library should emit a contactAdded() signal when the operation is complete.
• ISF and Mimic will be disabled by compiler flags, and cmake will use the bundled copies of these libs if they are not available system-wide.