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)
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.
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.)
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.
One account represents one 'user account' on one protocol.
Roster / Contact list
Support for 'merging' multiple accounts (ie. you might want to have your jabber and ICQ contacts in one contact list .. without separating them)
Support to group multiple contacts together to form one 'metacontact' (e.g. when you have one person in jabber,icq,msn, or whatever.. you might only want 1 visible contact in your roster)
-> support for client side saving of the roster … and saving additional information about contacts. (some protocols may not support server side storage.. )
Which information should be stored by the protocol extensions themselves.. and which centrally ?? and how ? (e.g. grouping needs to be saved centrally)
Support for avatars (? how ?)
Should support one-on-one as well as group chats.
Support for XHTML
Is currently implemented to support jabber-like XHTML .. i think this is the best abstract way to handle this..
other protocols which do not support XHTML like behaviour should be allowed to disable markup alltogether
protocols which support another form of markup need to convert XHTML into whatever they need
Smileys should be handled centrally..
Should be allowed to contribute icons / buttons to contact list and chatwindow (e.g. for filetransfer, vcard, etc.)
Need to support .....
Configuring an account
Protocol Extensions provide their own GUI
Changing status (if offline before, login, if change to offline -> logout)
+ away message
'service discovery' ??? (is it possible to make it generic enough for all protocols ?)
joining groupchats ?
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.
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 ...)
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.
Should every protocol implement it's own UI for vcard ? or is it general enough ?
propably every protocol should define it's own UI .. but it should be REQUIRED that every protocol has a feature for getting user information.
As stated before.. no idea how to make it generic enough
Joining Groupchats ?
In Jabber this is only possible through service discovery .. so how could this be made generic enough ?
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)
User-readable name of the protocol (e.g. 'Jabber')
Interface: GOIMProtocol - the basis class which is responsible for everything.
Interfaces/Classes implemented by Protocol extensions
Interfaces/Classes implemented by Protocol extensions
void editAccount(GOIMAccount account, Control parent) - provides the GUI to edit a specific account (puts it's GUI components into 'parent')
GOIMAccount createAccount() - creates a GOIMAccount object
void changeStatus(GOIMStatus status);
GOIMProtocolConnection getConnection(); // returns null if not connected
Interface GOIMRosterGroup - Recursive group within a GOIMRoster
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
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
account: the associated account (GOIMAccount)
protocol: the protocol extension where this event happened (redundant ? the same information can be found in GOIMAccount)
direction: incoming/outgoing (ie. also if the user sends a message, it is still an event which will be received by the protocol extension through the same event handler it will send incoming events.)
shown: boolean if it was already shown to the user (if more than one event listener is available this can be useful, so that the in-game messenger displays it .. and pops up .. but the chat GUI window only displays it, but does not pop up)
participant: the other side of this event (ie. if incoming: the sender .. if outgoing: the destination) - should be it's own class .. not just a string… GOIMContact (? perhaps a better name ? since we might want to send events to/from people which are not 'contacts' ?)
GOIMStatus (May be subclassed by protocol extensions)
type: online/away/extended away (not available)/do not disturb/invisible/offline