Re: [ecf-dev] Radical proposal

[Tim Terlegård <tim@xxxxxxxxxxxx>]

> >A not so complex ECF
> >--------------------
> >IContainer client = ContainerFactory.createContainer("ecf.xmpp.smack");
> >
> >ID server = client.createID("jabber.org");
> >client.connect(server, new Auth("tim", "password"));
> >
> >IChatRoomContainer chatRoom = 
> >client.getAdapter(IChatRoomManager.class).join("timtest");
> >chatRoom.sendMessage("howdy");
> >
> ></code>
> >
> 
> Four reactions:
> 
> 0) Thanks for the thoughts
> 1) Some of the suggested simplifications can/could be made...and it 
> would be very worthwhile to do so
> 2) Some of the suggested simplifications would make the API very 
> specific to (xmpp) IM/chat...which would not be appropriate for ECF as a 
> whole.  Much of the reason for the extra complexity in the ECF core API 
> is to be able to handle other (non-im, non-chat) asynch comm protocols 
> with a single API
> 3) Some of the suggested simplifications would be in violation of some 
> Eclipse platform conventions (e.g. the use of getAdapter...which has a 
> very specific contract...and ECF should use it in a consistent manner)
> 
> I would suggest a strategy of us creating utility classes (in 
> org.eclipse.ecf.presence...the presense API specifically) that 'wrap' 
> ECF core APIs with IM/chat-specific functions...in a way more like 
> you've suggested above...e.g. the 'Auth' class...or a 'custom' adapter.  
> That way the IM/chat APIs can be simpler/shorter, but the core can be 
> used outside of the context of xmpp IM/chat without a 'force fit'.  What 
> do you think?  This would allow an API very much like what you've 
> presented as the 'not so complex ECF', but still allow the core API to 
> remain sufficiently general.

Only a computer nerd starts to count his thoughts at 0  ;)

What parts are IM specific? What parts are violating Eclipse platform
conventions? 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()?

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?

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 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.

Tim