The ECF development team is considering at least four distinct types of chat use cases depending on whether GroupIDs and chat SharedObject IDs are well-known or not. We have given each of the types a name suggested by the manner in which it would be used. This name is not really the important issue. What's important here is the combination of well-known and individualized IDs.

1. ChatRoom -- GroupID well-known, Chat SharedObject ID well-known

In this case everyone knows a common familiar GroupID, e.g., "server.com" and joins that container. They also create a SharedObject with the well-known ID, "chat". This is a big space that anyone with permission to use "server.com" may enter.

2. IM -- GroupID well-known, Chat SharedObject ID individualized

We all join a well-known container for some purpose. It doesn't have to be to chat. We might have joined the container for the purpose of learning about people's online status. Then, you decide that you would like to chat with someone, but don't want to go to the trouble of creating a new container for that purpose. So, instead, you create a ChatSharedObject, but give it a unique ID. Then, you direct some other group member to create that ChatSharedObject as well. Now, we can use the chat, but others are not aware of our chat and cannot participate.

Note: The privacy afforded by this approach depends somewhat on whether getSharedObjectIDs returns all the IDs known at the container or only the ones created by any user.

3. Chat Meeting -- GroupID individualized, Chat SharedObject ID well-known

1. We all join a well-known container that we call the Lobby. Let's say it has a GroupID of "server.com/lobby" and provides some way to send invitations from one user to another.


2. One user creates a new container and joins it by creating a unique GroupID for the chat, e.g., "server.com/mychat". In addition, the user adds a ChatSharedObject with the well-known ID, "chat".


3. This first user sends an invitation to another user via the lobby to let the second user know that they are invited to the "server.com/mychat" container. (Presumably, it would also be good to send information about the container type, just in case we want to support multiple types of meetings.


4. The second user joins the meeting by creating the appropriate chat container, adding in the appropriate chat object, and joining with the "server.com/mychat" GroupID.

4. Whisper -- GroupID individualized, Chat SharedObject ID individualized

Let's imagine that the ChatMeeting identified above has been joined by many people and we now want to support a private conversation among a subset of the participants. Assuming we are too lazy to create a new container for the purpose, one user might create a new chat object with an individualized ID, then, as in the IM case, they would instruct another user to create the object as well.

Chat Use Case Considerations

One thing the ECF development team with these use cases is to begin to tie specific communication features to patterns in the use of ECF containers and shared objects. For example, say that you had a 'well-known' chat, and you wanted to have a feature that started a shared whiteboard with the same set of participants. Well, one way to implement this would be to have the chat create a new shared object (a whiteboard component) that implemented the whiteboard communications functionality (i.e. keeping the whiteboard state synchronized) and the whiteboard UI. In this way, the whiteboard functionality would be separable from the chat, and usable within different communications contexts. The whiteboard component could even be implemented to run similarly on multiple container implementations (multiple providers)...e.g. SIP or XMPP or whatever. In this way a library of components could be created, implemented as shared objects (in this case), or combinations of shared objects and provider implementations (less desirable from a component design point of view).

In any event, we think that with a variety of use cases (these and others) and a couple of functioning providers (coming very shortly), we can experiment a little bit with the design of communications components, and begin to connect various features with individual components or sets of components (implemented as independent shared objects, shared objects with connectors, patterns of classes used by shared objects, custom containers, etc).