[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

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

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.