blob: 382490704148675a52c1fba45a519cdf2fab7cfa [file] [log] [blame]
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>eclipse communication framework use cases</title>
<link rel="stylesheet" href="" type="text/css">
<body bgcolor="#FFFFFF">
<table border=0 cellspacing=5 cellpadding=2 width="100%">
<td width="69%" class="bannertext"><font class="indextop style2">eclipse communication framework use cases</font>
<font class="indexsub"></font>
<td width="31%"><div align="center"><img src="../images/Idea.jpg" width="120" height="86"
hspace="50" align="middle"></div></td>
<table border=0 cellspacing=5 cellpadding=2 width="100%" >
<td align=left valign=top bgcolor="#0080C0">
<font color="#FFFFFF" face="Arial,Helvetica">
&nbsp;<b>Chat Use Case</b>
<td valign="top">
<p>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.</p>
<h4>1. ChatRoom -- GroupID well-known, Chat SharedObject ID well-known</h4>
<p>In this case everyone knows a common familiar GroupID, e.g., "" 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 "" may enter.</p>
<h4>2. IM -- GroupID well-known, Chat SharedObject ID individualized</h4>
<p>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.</p>
<p><u>Note</u>: 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.</p>
<h4>3. Chat Meeting -- GroupID individualized, Chat SharedObject ID well-known</h4>
</p>This case requires two containers: one for the actual chat and one to communicate
the individualized GroupID of that chat.</p>
<li>We all join a well-known container that we call the Lobby.
Let's say it has a GroupID of "" and provides some
way to send invitations from one user to another.</li><br>
<li>One user creates a new container and joins it by creating a unique
GroupID for the chat, e.g., "". In addition, the
user adds a ChatSharedObject with the well-known ID, "chat".</li><br>
<li>This first user sends an invitation to another user via the lobby
to let the second user know that they are invited to the
"" 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.</li><br>
<li>The second user joins the meeting by creating the appropriate chat
container, adding in the appropriate chat object, and joining with
the "" GroupID.</li>
<h4>4. Whisper -- GroupID individualized, Chat SharedObject ID individualized</h4>
<p>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.</p>
</p><u>Note</u>: 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.</p>
<h4>Chat Use Case Considerations</h4>
<p>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).</p>
<p>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).</p>