| Re: [ecf-dev] Radical proposal |
|
Hi Tim, Tim Terlegård wrote: Only a computer nerd starts to count his thoughts at 0 ;) guilty as charged I guess What parts are IM specific? Any of the org.eclipse.ecf.presence interfaces: IPresenceContainer, IChatRoomContainer, etc What parts are violating Eclipse platform conventions? The IAdaptable contract is the main one. What parts are better suited as util classes/methods? 1) In my "proposal" I made creation of IDs easier. Creating the chat room id was especially complex. ID is a core concept and IContainer knows about namespaces and other stuff that's needed to create protocol specific IDs, so I thought createID() would fit in the IContainer interface. Or perhaps IContainer.getIDFactory().createID(...) would be something? Or IContainer.getAdapter(IIDFactory.class).createID()? The ID creation could very well be simplified via util classes/methods...basically removing any need to consider the id Namespace. 2) What does ConnectContextFactory do? I looked inside the class, but didn't get any wiser. So I thought Auth would be easier. I guess that would suite fine as a util class. Or perhaps an overloaded connect() that can both take a ConnectContext or Auth? It could be wrapped by an Auth class for simplification. 3) The third thing is joining a chat room. There are too many steps involved. In IPresenceContainer there is a getChatRoomManager method. Does it really belong there? To me it's just about chat while presence doesn't have to be in the chat/im space at all. What computers do I have in my network at the moment? That's presence, but I don't want to chat with any of the computers even if they are cute. So, imho, a chat room manager would better be retrieved using the getAdapter. Using join on a IChatRoomManager would be a convenient way to join a chat room and get an IChatRoomContainer instance back. Does that violate any design decision? And what about adding sendMessage() to IChatRoomContainer, is that evil? I'm in agreement that there are too many steps...but I do think that utility classes can essentially wrap the steps...e.g. ignoring presence and chat room managers, etc. I like elegant code, but I don't like to violate good design. You're the expert here, so please tell what is good and what is bad. No good and bad here...just designs that need to be a) as simple as possible b) general enough not to be IM/chat/xmpp specific c) in keeping with the basic approaches/conventions of Eclipse/OSGI, etc I'm sorry...I'm a little strapped for time at the moment...so can't respond more fully to your questions, etc...but let's keep the dialog about this open...I'm more than happy to both revise the apis for simplification and write utility classes, etc to get to something appropriately easy and general. Again...sorry for the delay in further discussion...I'm just bandwidth limited right now. Scott |