Development/MultiProtocol

(Development/MultiProtocol@groupWiki:goim) 703 Hits - Changes: 8 - Last Change: 2006-09-30 23:29:32 by Herbert Poul (Kahless) - [ History ] [ Latest changes ]

A collection of thoughts which needs to be done to support multiple protocols ..

(I suggest development of Multi Protocol Support starts in a separate branch. so development on the current version can continue in the trunk. - GOIM with multi protcol support will be labeled GOIM 2.0 (imo this is a major feature improvement.. and might take a few months to implement.. so it's worth to increment version number)

Target

Altough multi protocol support sounds good, the main protocol should remain jabber. And some features will require jabber accounts. And new users will be prompted for ONLY a jabber account at first.. (to avoid confusion .. ie. support more, but still keep it as simple as possible)

As currently handled with contact lists / chat windows additional protocols should be created through eclipse extension points. They provide a good and easy way to define extensibility. Additional protocols should plug into the contact list and chat windows which already exist. And should need to create as few custom windows as possible.

Since this can only be successful if people are found to maintain protocols other than jabber it is necessary to create useful documentation and examples on how to use these extension points and how to add new protocols.

Terminology

The terminology should stick to the jabber terminology.. e.g. Roster (not contactlist/buddylist when talking about the server-stored list of contacts) / RosterEntry / etc.)

Basic Featureset

There needs to be a separation between the basic featureset supported by all protocols and therefore needs an abstraction layer and features specific to each protocol which needs to be handled by each protocol extension on it's own.

Accounts

One account represents one 'user account' on one protocol.

Roster / Contact list

ChatWindow

Should support one-on-one as well as group chats.

Protocol Extensions

Events

Currently message listeners, file transfer listeners, MUC invite listeners, subscribe requests, etc. are handled separately ..

there should be a general GOIM-way to handle events. ie. add an abstraction layer for events. This way we can allow events to be shown in the contact list before popping up..

and we can centrally configure how events should be handled.

Current Status

Currently Jabber (ie. smack) classes are used throughout GOIM. Mostly by accessing it through the GOIMAccount object which contains an XMPPManager (more or less a small wrapper around smack ...)

Plans

This need to change .. All smack related features should move in a separate project called "net.sphene.goim.jabber" and only integrated through the extension point(s) and through interfaces.

Neither the contact list nor the chat window should need to directly access smack classes.

Considerations

Implementation

Draft of how to implement all needed features.

There is a strict separation between the protocol implementation and the GUI.

Most GUI elements will be provided by GOIM itself (ie. through other extension points.. which are not part of this document)

Interfaces/Classes implemented by Protocol extensions

GOIMRoster:

i would like to have the possibility to group different jabber ids/icq numbers/etc. together to one real 'contact' in the roster.

either.. having GOIMRosterGroup and GOIMRosterContact where as GOIMRosterContact has a subclass called GOIMRosterContactGroup which may group together several 'real' contacts.

or having it totally separated… (ie. GOIMRosterContact is a own object.. not related to GOIMRosterGroup)

GOIM-Implemented classes

There should be one central GOIMEventHandler where all events will be fired and handled.

A GOIMEvent is everything which can happen through ANY IM protocol. therefore it is required that a GOIMEvent is extensible so IM specific features are also represented



0 Comments
You need to be logged in to post a Comment !