[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:
ECF is cool, no doubt about that. But the API is, IMHO, a bit verbose
and complex. I made a simple xmpp client that joined a chat room and
said hi. Here are three pieces of code. The first is using just the
Smack library. The second uses ECF. The third is how I would like it in


XMPPConnection conn = new XMPPConnection("jabber.org");
conn.login("tim", "password");
MultiUserChat chat = new MultiUserChat(conn, "timtest@xxxxxxxxxxxxxxxxxxxxx");

ECF --- IContainer client = ContainerFactory.getDefault().createContainer("ecf.xmpp.smack"); ID server = IDFactory.getDefault().createID(client.getConnectNamespace(), "tim@xxxxxxxxxx"); IPresenceContainer presence = (IPresenceContainer) client.getAdapter(IPresenceContainer.class);

client.connect(server, ConnectContextFactory.createPasswordConnectContext("password"));

IChatRoomManager chatmanager = presence.getChatRoomManager();
IChatRoomContainer chatroom = chatmanager.createChatRoomContainer();
ID roomID = IDFactory.getDefault().createID(chatroom.getConnectNamespace(), new Object[] {"tim","jabber.org",null,"timtest","santa"});
chatroom.connect(roomID, null);
IChatMessageSender chatSender = chatroom.getChatMessageSender();

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");


Note that I'm no well-known super architect and don't know the ins
and outs of ECF, so this might be crazy. What are your reactions?

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.

I began the creation of a few of these utility classes in org.eclipse.ecf.example.clients...but they could/should be generalized and then they could be moved/exposed via org.eclipse.ecf.presence when they are sufficiently done.