Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Chatroom ID
Hi Tim,

Tim Terlegård wrote: 
You say it changes the meaning of container.getAdapter.
Well, the contract for IAdaptable is extremely general:

 * Adaptable objects can be dynamically extended to provide different
 * interfaces (or "adapters").  

Please tell me
(or us) what the meaning of getAdapter is.

In the ECF context of an adapter for IContainer, it's meaning has been to provide 'protocol adapters'...access to the abstract API contract implied by a given protocol (e.g. 'presence', 'file sharing', 'data sharing', 'call setup', etc).   This so that various communications semantics can be exposed to applications, and various providers can respond to 'queries' (i.e. getAdapter(IPresence.class) returning null/IPresence instance is a runtime indication that the given provider does/does not expose presence communications behavior).

In haste, I spoke a little inprecisely when saying that it changes the meaning of getAdapter.  It doesn't actually change the meaning of getAdapter...rather it generalizes the usage of getAdapter for IContainers to include access to ID creation factories (IChatRoomIDFactory) in addition to the specialized use to access various communications protocols described above.  Which may be perfectly fine...I'm just mulling over whether such a convention (having the container expose adapters via getAdapter for ID creation factories) should perhaps be made more general (i.e. used to expose 'specialized' ID factories), or whether specialized ID factories can/should be exposed other (perhaps more natural) ways.

I have got the feeling it
works like a factory. You specifiy "xmpp.smack" once and based on that
you create IDs, other containers and other stuff based on the "root"
container. You don't have to specify "xmpp.smack" everytime you create
something. That's what I thought it was about. But there might be
something more to it?

I don't at all object to the notion of a factory that is customized for creating certain types of IDs, (or containers, or other ECF things).  I also don't object to the notion of exposing such a factory as an adapter off of a container (i.e. via container.getAdapter(<factory interface class>)...I'm just trying to mull over how other customized ID factories can/would/should be exposed through such a convention.  Maybe this is a specialized case (chat room IDs), but I get the sense that customized ID factories are going to be needed for other types of IDs, and I would like to have a clear idea of a pattern that would work similarly (and as clearly as possible) in all cases.

So just thinking about this...all comments welcome.

Scott

Tim


  
I'm mulling over Tim's thoughts...and have some affinity for #2 as 
well...although it sort of changes the meaning of container.getAdapter 
somewhat...which may be OK.

It also may be possible to use an idiom like:

ID newID = 
IDFactory.getDefault().createID(c.getConnectNamespace(),"xmpp_room:slewis@xxxxxxxxxxxxxxxxxxxxxxxxxx/room");

I should have probably had this supported in XMPP room ID creation 
anyway.  The XMPP conference room identification (e.g. 
conference.ecf.eclipse.org/room) is sort of clumsy IMHO...which sort of 
exacerbates this design problem.

OTOH, I do like #2 from Tim below for compactness.

Any thoughts/discussion?

Scott


Tim Terlegård wrote:
    
Creating a generic chatroom ID is hard, too hard IMHO. We talked about
util methods, but should it really be so hard in the core API?

I couldn't come up with a perfect solution. I've come up with 3 possible
solutions. If you want to create a chatroom ID right now you do something
like this:

ID chatRoomID =
   IDFactory.getDefault().createID(chatroom.getConnectNamespace(),
   new Object[] {"user", "host", "domain", "room", "nickname"});

It took quite a while before I realized how to create that ID correctly.
Possible solution I come up with:

1)

class XMPPChatManager implements IChatManager {
  public void join(String room, String nick) {
     IChatRoomContainer chat = createChatRoomContainer();
     ID id = new XMPPRoomID(chat.getConnectedNamespace(),
                            xmppConnection, "room", "nick");
     chat.connect(id, null);
     return chat;
  }
}

It makes it easier to join a chatroom and it hides the ID creation, but
it's still hard to create a generic chatroom ID using the core API.

2)

IChatRoomContainer chat = chatManager.createChatRoomContainer();
IChatRoomIDFactory f = chat.getAdapter(IChatRoomIDFactory.class);
f.createID("room", "nick");

3)

class XMPPRoomNamespace extends ChatRoomNamespace {
  public ID createInstance(String room, String nick) {
     return createInstance(...);
  }
}

ChatRoomNamespace chat = (ChatRoomNamespace) 
container.getConnectedNamespace();
IChatRoomID chatRoomID = chat.createInstance("room", "nick");

But the chatRoomID still miss information about username and domain.

I like solution 2, but I suspect it's not the Eclipse way?

Tim
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
 
      
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
    
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top