chatusecase.html

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>eclipse communication framework use cases</title>
<link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css">
</head>
<body bgcolor="#FFFFFF">
</table>
<table border=0 cellspacing=5 cellpadding=2 width="100%">
  <tbody>
    <tr>
  <td width="69%" class="bannertext"><font class="indextop style2">eclipse communication framework use cases</font>
      <br><br>
      <font class="indexsub"></font>
   </td>
  <td width="31%"><div align="center"><img src="../images/Idea.jpg" width="120" height="86"
          hspace="50" align="middle"></div></td>
    </tr>
  </tbody>
</table>
<table border=0 cellspacing=5 cellpadding=2 width="100%" >
  <tr>
    <td align=left valign=top bgcolor="#0080C0">
	  <font color="#FFFFFF" face="Arial,Helvetica">
        &nbsp;<b>Chat Use Case</b>
	   </font>
	</td>
  </tr>
    <tr>
    <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>
   <hr>
    <h4>1. ChatRoom -- GroupID well-known, Chat SharedObject ID well-known</h4>
    <p>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.</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>

    <ol>
      <li>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.</li><br>
      <li>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".</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
      "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.</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 "server.com/mychat" GroupID.</li>
    </ol>

	<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>
   <hr>
    <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>

    </td>
  <tr>
  </table>

</body>
</html>