Since i couldn't get my head around designing everything as perfect as i wished i could.. (GOIM2 needed to get done somehow :) ) i try to collect my thoughts here so i could get back to those things and try to fix them (if .. anything is actually wrong with them)

1. Contact List Entries

There are currently 3 important contact list entries:

• IContactListContact (representing a real contact on some protocol)
• IContactListGroup (a group within our contact list - might or might not be represented as a real group in some protocol)
• IContactListMetaContact (this is not really implemented - one day it should allow users to group contacts which actually represent the same person in real life (e.g. because you have him in several protocols) to group together so he apaers as one contact in your contact list)

This is all fine and perfect. Except that the implementation is spread accross several classes. - It would be much nicer if the ContactListUI would not know how to handle each single of those types.. if this would be possible.

Another thing is the current implementation of switching the groups of a user. The AbstractContactListUI#getMenuManagerForEntry will create a 'Change Group' submenu for all 'IContactListContact' - ie. not for meta contacts.. or for groups themselves.. This is not really that nice.. and it has to check by itself (or better said the ChangeContactListContribution class) if the user is connected to the protocol in which the IContactListContact is in. (Otherwise he can't change groups)

2. IUser

currently it defines a method 'setName(..)' which allows the caller to modify the handle of the user in the contact list.

This is all nice and good, but a 'DefaultPeer' object is created for ever incoming packet - this class extends DefaultUser, which implements IUser .. the problem is that it would be much better if IPeer would hold a reference to IUser - The same with IContactListContact and IUser .. This way there could be only one IUser object.. so if the name is changed it is automatically reflected everywhere..

in addition it would need a few listeners so the UI can be updated immediately.

3. Contact List Context Menu

The AbstractContactListUI currently manages it's own MenuManger through it's own extension point. (Just because i didn't know how to do it the eclipse-way) - see http://www.eclipse.org/articles/article.php?file=Article-action-contribution/index.html - ie. register the MenuManager using org.eclipse.ui.IWorkbenchPartSite.registerContextMenu(MenuManager menuManager, ISelectionProvider selectionProvider)

4. Game Instance Provider

Currently the game instance provider only supports game instances from type 'SimpleGameInstance' - the reason for this is, that it is serialized using standard java serialization .. which would not work if the classes which need to be loaded come from another classloader..

it would be better to use IMemento - and each game instance provider should be responsible on it's own to serialize and deserialize the stored game instances.