[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] Radical proposal
|
> >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