chatusecase.html - gerrit/www.eclipse.org/ecf - Git at Google

 <!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>
	<!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">
	<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>