Home » Archived » Eclipse Communications Framework (ECF) » Starting a Chat Use Case
| Starting a Chat Use Case [message #570605] |
Tue, 14 December 2004 17:11  |
Eclipse User |
|
|
|
Originally posted by: john_patterson.us.ibm.com
It would help me if we identified a few use cases and worked them
through using the API. The simplest is probably starting a chat. We
can worry later about actually using the chat. For now, I just want to
understand how it all gets started.
Normally, I think of chat as having three main steps to get it going:
1. One user initiates a chat session.
2. Somehow another user becomes informed of the existence of the chat
(the invite)
3. The second user joins the chat.
For step 1), I assume that I create a SharedContainer to correspond to
the chat session. Then I create a SharedObject that will be used to
accomplish the actual communication.
For step 2), I assume I must send the ID of the SharedContainer to the
other user. I don't believe the ECF provides an explicit way to do
this, but one could be invented on top of it.
For step 3), I assume the second user creates a SharedContainer of the
appropriate type (how do they know the type?) and Join the group
identified by the ID sent to them. Then somehow, they find the
SharedObject.
Do I have this right, as far as it goes? As you can see, I am a little
unclear on some of the specifics, particularly on how the SharedObjects
come to exist on the second machine. Are they brought into existence
upon joining the group? Does the second user learn about them via an event?
I would find it helpful to see the code for this use case.
|
|
|
| Re: Starting a Chat Use Case [message #570650 is a reply to message #570605] |
Tue, 14 December 2004 19:30  |
 Li-Te Cheng
Messages: 16
Registered: July 2009 |
Junior Member |
|
|
(note: newsgroup is acting funny .... seeing double posts. so apologies
if this appears twice, or if someone already answered John's question)
Here is my rough understanding of this from what I've read so far in the
javadoc and online documentation. Someone say something in if I'm wrong
here. Putting in "???" in unknown bits.
--- for user 1
// create a chat container - ignore what kind of protocols, etc for now
ISharedObjectContainer chatLobby =
SharedObjectContainerFactory.
makeSharedObjectContainer("chatLobby");
// set up listener for any messages sent to my container
chatLobby.addListener( ... );
// create a chat object, forget about transactional stuff for now
SharedObjectDescription chatObjectDescription = ...; // ???
ISharedObject user1 =
chatLobby.getSharedObjectManager().
createSharedObject(chatObjectDescription,null);
// put the chat object in the container associated with a given ID, and
// forget about properties and transactional for now
ID user1Id = IDFactory.makeGUID();
chatLobby.addSharedObject(user1Id,user1,null,null);
// need id where to "rendezvous" with user 2. lobbyInfo contains the
// details where to "meet" up on the chat service (e.g. a
// "public" channel)
Namespace chatLobbyNamespace = IDFactory.getNamespaceByName(...);
Object[] lobbyInfo = ...; // ???
ID chatLobbyId = IDFactory.makeID(chatLobbyNamespace,lobbyInfo);
// login
Object user1LoginData = ...; // authentication info
chatLobby.joinGroup(chatLobbyId,user1LoginData);
// just get the first member for now, assume it is a user
ID[] members = chatLobby.getSharedObjectIDs();
ID user2Id = members[0];
// find shared object associated with user2
ISharedObject user2 = chatLobby.getSharedObjectManager().
getSharedObject(user2Id);
// establish a 2-way messaging relationship between user1 and user2
chatLobby.connectSharedObject(user1Id,new ID[] {user2Id});
chatLobby.connectSharedObject(user2Id,new ID[] {user1Id});
// define a new container to hold the a 1-to-1 chat session
ISharedObjectContainer chatSession =
SharedObjectContainerFactory.
makeSharedObjectContainer("chatSession");
// add me into the session
chatSession.addSharedObject(user1Id,user1,null,null);
// and listen for any messages in this 1-to-1 session
chatSession.addListener(...);
// and make this available for only invited people to join in.
// any protections should be specified in invitationOnlyInfo?
Object[] chatSessionInfo = ...; // ???
ID chatSessionId = IDFactory.makeID(chatLobbyNamespace,chatSessionInfo);
Object invitationOnlyInfo = ...; // ???
chatSession.joinGroup(chatSessionId,invitationOnlyInfo);
// now prepare to invite user2...
// somehow get a ISharedObjectContext to use "sendMessage"
ISharedObjectContext lobbyContext = ...getConfig().getContext(); // ???
// send out the invitation in the "public" chatLobby
Object chatInvitationMessage = ...; // ???, pass along ID to chatSession
lobbyContext.createMessage(user2Id,chatInvitationMessage);
--- for user 2
// similar process like user 1 (log into a chat lobby) and
// then in the chatLobby listener defined by calling
// chatLobby.addListener(), check if an invitation message
// came through. the invite should hold chatSessionId so
// user 2 can do something like this
private void joinSession( ID chatSessionId )
{
ISharedObjectContainer chatSession =
SharedObjectContainerFactory.
makeSharedObjectContainer("chatSession");
// e.g. join info could might be a password if the chat room is
// protected
Object joinInfo = ...; // ???
chatSession.joinGroup(chatSessionId,joinInfo);
}
Several notes:
In this setup, there is a container for a "lobby", the public space to
discover other members. The lobby is where people can send invites, and
find out who's online (e.g. buddy list). Shared objects in the lobby
are really tokens for user presence : if user1's object is in the lobby,
then user1 is "online". Login is done via the join() method. Listing
who's online is done by listing what object IDs are in the "lobby"
container (after join() is called).
The lobby needs a unique ID for all users to connect to. This is done
by defining an ID via namespaces. IDFactory.getNamespace(...) would
define an appropriate namespace for IDFactory.makeID(...)
To start a chat, user1 creates another container for the 1-to-1 chat
session. join() here denotes creating a session for 1-to-1 access, so a
lot of this hinges upon the Object[] parameter in join()... this doesn't
feel quite right to me.
To invite user2, user1 sends a message to user2 in the lobby container
via a ISharedObjectContext... not sure how to get one of these context
objects. I don't see a ISharedObject.getContext() method. And
ISharedContainerObject.getConfig() doesn't return a ISharedObjectConfig
which has the needed getContext() method.
user2 would have to set up a listener in the lobby container for
invitation message types, and join the 1-to-1 chat session container by
calling join(). The ID of the chat session must be passed along in the
invitation message.
Does this sound right?
Li-Te
John F. Patterson wrote:
> It would help me if we identified a few use cases and worked them
> through using the API. The simplest is probably starting a chat. We
> can worry later about actually using the chat. For now, I just want to
> understand how it all gets started.
>
> Normally, I think of chat as having three main steps to get it going:
>
> 1. One user initiates a chat session.
> 2. Somehow another user becomes informed of the existence of the chat
> (the invite)
> 3. The second user joins the chat.
>
> For step 1), I assume that I create a SharedContainer to correspond to
> the chat session. Then I create a SharedObject that will be used to
> accomplish the actual communication.
> For step 2), I assume I must send the ID of the SharedContainer to the
> other user. I don't believe the ECF provides an explicit way to do
> this, but one could be invented on top of it.
> For step 3), I assume the second user creates a SharedContainer of the
> appropriate type (how do they know the type?) and Join the group
> identified by the ID sent to them. Then somehow, they find the
> SharedObject.
>
> Do I have this right, as far as it goes? As you can see, I am a little
> unclear on some of the specifics, particularly on how the SharedObjects
> come to exist on the second machine. Are they brought into existence
> upon joining the group? Does the second user learn about them via an
> event?
>
> I would find it helpful to see the code for this use case.
|
|
|
| Re: Starting a Chat Use Case [message #570783 is a reply to message #570650] |
Wed, 15 December 2004 22:26 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010108020908000103040308
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Li-Te and all,
Here are some comments on Li-Te's chat application.
Li-Te wrote:
> (note: newsgroup is acting funny .... seeing double posts. so apologies
> if this appears twice, or if someone already answered John's question)
>
> Here is my rough understanding of this from what I've read so far in the
> javadoc and online documentation. Someone say something in if I'm wrong
> here. Putting in "???" in unknown bits.
>
> --- for user 1
>
> // create a chat container - ignore what kind of protocols, etc for now
> ISharedObjectContainer chatLobby =
> SharedObjectContainerFactory.
> makeSharedObjectContainer("chatLobby");
Yes. This is the first step...to create a container for the chat.
In preference to all of the code you have below, I would design things
so that the program would be structured as follows:
// join the group...this connects to some server...using any/all
// authentication required by 'chatLobby'
chatLobby.joinGroup(IDFactory.makeStringID("slewis@server.com",null);
// Create an ISharedObject that represents me...i.e. has my nickname
Chat chat = new Chat("slewis");
// And add the shared object to the container...this will init the Chat
// instance and allow it to start sending/receiving messages
chatLobby.getSharedObjectManager().addSharedObject(IDFactory .makeStringID( "chat"),chat,new
Properties(),null);
For a simple chat, this would be all I would need. All the
functionality of sending/receiving messages would be implemented in the
Chat class. I've attached a copy of the source to this class in this
email, and I'll also be checking it in to the org.eclipse.ecf.test
plugin later today.
User two would have *exactly the same code* except for
"slewis@server.com" would be changed to "li-te_cheng@us.ibm.com"
and new Chat("slewis") would be changed to "li-te". The Chat object
code itself would also be the same on both/all participants.
There would be other ways to implement this functionality, but I think
this is the most straightforward. The basic notion is that the
ISharedObject is really responsible for implementing all of the 'chat'
functionality (or presence functionality, or file sharing functionality,
etc).
Some more comments are interspersed below:
<code deleted>
> --- for user 2
>
> // similar process like user 1 (log into a chat lobby) and
> // then in the chatLobby listener defined by calling
> // chatLobby.addListener(), check if an invitation message
> // came through. the invite should hold chatSessionId so
> // user 2 can do something like this
>
> private void joinSession( ID chatSessionId )
> {
> ISharedObjectContainer chatSession =
> SharedObjectContainerFactory.
> makeSharedObjectContainer("chatSession");
>
> // e.g. join info could might be a password if the chat room is
> // protected
> Object joinInfo = ...; // ???
> chatSession.joinGroup(chatSessionId,joinInfo);
> }
>
>
> Several notes:
>
> In this setup, there is a container for a "lobby", the public space to
> discover other members. The lobby is where people can send invites, and
> find out who's online (e.g. buddy list). Shared objects in the lobby
> are really tokens for user presence : if user1's object is in the lobby,
> then user1 is "online". Login is done via the join() method. Listing
> who's online is done by listing what object IDs are in the "lobby"
> container (after join() is called).
Yes.
>
> The lobby needs a unique ID for all users to connect to. This is done
> by defining an ID via namespaces. IDFactory.getNamespace(...) would
> define an appropriate namespace for IDFactory.makeID(...)
Yes.
>
> To start a chat, user1 creates another container for the 1-to-1 chat
> session. join() here denotes creating a session for 1-to-1 access, so a
> lot of this hinges upon the Object[] parameter in join()... this doesn't
> feel quite right to me.
As my example above shows, this isn't strictly necessary. There's no
reason to have the container create a new container for this simple chat
case. To implement a 'multiple chat groups with a lobby chat' sort of
approach it might be helpful to define new containers to represent other
chat groups, but it's not necessary for this simple chat
>
> To invite user2, user1 sends a message to user2 in the lobby container
> via a ISharedObjectContext... not sure how to get one of these context
> objects. I don't see a ISharedObject.getContext() method.
It's on the ISharedObjectConfig that is passed to the shared object via
the 'init' method. ISharedObjectConfig.getContext(). This is
explicitly modelled after the ServletConfig/ServletContext relationship.
/And
> ISharedContainerObject.getConfig() doesn't return a ISharedObjectConfig
> which has the needed getContext() method.
No, the ISharedObjectContainer.getConfig() is the config associated with
the container (not the config associated with the ISharedObject).
>
> user2 would have to set up a listener in the lobby container for
> invitation message types, and join the 1-to-1 chat session container by
> calling join(). The ID of the chat session must be passed along in the
> invitation message.
>
> Does this sound right?
Well yes, except that I would put most of what you are describing for
invitation messages and etc in the implementation of the Chat class.
The chat class I've provided simply sends around nickname/message
pairs...but an invitation message could easily also be defined/responded
to within the Chat class itself as you describe.
Hopefully this helps.
Scott
>
> Li-Te
>
>
> John F. Patterson wrote:
>
>> It would help me if we identified a few use cases and worked them
>> through using the API. The simplest is probably starting a chat. We
>> can worry later about actually using the chat. For now, I just want
>> to understand how it all gets started.
>>
>> Normally, I think of chat as having three main steps to get it going:
>>
>> 1. One user initiates a chat session.
>> 2. Somehow another user becomes informed of the existence of the chat
>> (the invite)
>> 3. The second user joins the chat.
>>
>> For step 1), I assume that I create a SharedContainer to correspond to
>> the chat session. Then I create a SharedObject that will be used to
>> accomplish the actual communication.
>> For step 2), I assume I must send the ID of the SharedContainer to the
>> other user. I don't believe the ECF provides an explicit way to do
>> this, but one could be invented on top of it.
>> For step 3), I assume the second user creates a SharedContainer of the
>> appropriate type (how do they know the type?) and Join the group
>> identified by the ID sent to them. Then somehow, they find the
>> SharedObject.
>>
>> Do I have this right, as far as it goes? As you can see, I am a
>> little unclear on some of the specifics, particularly on how the
>> SharedObjects come to exist on the second machine. Are they brought
>> into existence upon joining the group? Does the second user learn
>> about them via an event?
>>
>> I would find it helpful to see the code for this use case.
--------------010108020908000103040308
Content-Type: text/plain;
name="Chat.java"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Chat.java"
package org.eclipse.ecf.test.ui.actions;
import java.io.IOException;
import org.eclipse.ecf.core.ISharedObject;
import org.eclipse.ecf.core.ISharedObjectConfig;
import org.eclipse.ecf.core.ISharedObjectContext;
import org.eclipse.ecf.core.SharedObjectInitException;
import org.eclipse.ecf.core.events.RemoteSharedObjectEvent;
import org.eclipse.ecf.core.identity.ID;
import org.eclipse.ecf.core.util.Event;
public class Chat implements ISharedObject {
public Chat(String nickname) {
super();
}
String nickname;
ISharedObjectConfig config;
public void init(ISharedObjectConfig initData)
throws SharedObjectInitException {
this.config = initData;
}
public ID getID() {
if (config == null) return null;
else return config.getSharedObjectID();
}
public void handleEvent(Event event) {
// This is the code to handle a
if (event instanceof RemoteSharedObjectEvent) {
// We've got an instance of event sent by remote
// We'll assume it's a chat message
RemoteSharedObjectEvent chatEvent = (RemoteSharedObjectEvent) event;
handleChatEvent(chatEvent);
} else System.out.println("ID: "+getID().getName()+" got unknown event: "+event);
}
protected void handleChatEvent(RemoteSharedObjectEvent chatEvent) {
// It's actually an object array...see sendChatToRemote
Object [] data = (Object []) chatEvent.getData();
showChatToUI((String) data[0], (String) data[1]);
}
protected void showChatToUI(String senderNickname, String message) {
System.out.println("Received chat message from: "+senderNickname);
System.out.println("Message: "+message);
}
// This is method to call to send message to remotes
protected void sendChatToRemote(String message) {
ISharedObjectContext ctx = config.getContext();
Object [] data = new Object[] { nickname, message };
try {
// Note that null means to *all* remotes in current container
ctx.sendMessage(null,data);
} catch (IOException e) {
e.printStackTrace();
}
}
public void handleEvents(Event[] events) {
for(int i=0; i < events.length; i++) {
handleEvent(events[i]);
}
}
public void dispose(ID containerID) {
System.out.println("ID:"+getID().getName()+" dispose("+containerID.getName()+")");
config = null;
}
public Object getAdapter(Class clazz) {
System.out.println("ID:"+getID().getName()+" getAdapter("+clazz.getName()+")");
return null;
}
}
--------------010108020908000103040308--
|
|
|
| Don't the Group IDs need to be the same? [message #570882 is a reply to message #570783] |
Thu, 16 December 2004 18:16 |
| Eclipse User |
|
|
|
Originally posted by: john_patterson.us.ibm.com
This is a multi-part message in MIME format.
--------------080303020306050706080803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I'm confused. You indicate below that one person uses
"slewis@server.com" for the GroupID and the other uses
"li-te_cheng@us.ibm.com" for the GroupID. If they don't use the same
GroupID, how do they ever get their local proxies ties together.
What am I missing?
Scott Lewis wrote:
> Hi Li-Te and all,
>
> Here are some comments on Li-Te's chat application.
>
> Li-Te wrote:
>
>> (note: newsgroup is acting funny .... seeing double posts. so
>> apologies if this appears twice, or if someone already answered
>> John's question)
>>
>> Here is my rough understanding of this from what I've read so far in
>> the javadoc and online documentation. Someone say something in if
>> I'm wrong here. Putting in "???" in unknown bits.
>>
>> --- for user 1
>>
>> // create a chat container - ignore what kind of protocols, etc for now
>> ISharedObjectContainer chatLobby =
>> SharedObjectContainerFactory.
>> makeSharedObjectContainer("chatLobby");
>
>
> Yes. This is the first step...to create a container for the chat.
>
> In preference to all of the code you have below, I would design things
> so that the program would be structured as follows:
>
> // join the group...this connects to some server...using any/all
> // authentication required by 'chatLobby'
> chatLobby.joinGroup(IDFactory.makeStringID("slewis@server.com",null);
>
> // Create an ISharedObject that represents me...i.e. has my nickname
> Chat chat = new Chat("slewis");
>
> // And add the shared object to the container...this will init the Chat
> // instance and allow it to start sending/receiving messages
> chatLobby.getSharedObjectManager().addSharedObject(IDFactory .makeStringID( "chat"),chat,new
> Properties(),null);
>
> For a simple chat, this would be all I would need. All the
> functionality of sending/receiving messages would be implemented in
> the Chat class. I've attached a copy of the source to this class in
> this email, and I'll also be checking it in to the
> org.eclipse.ecf.test plugin later today.
>
> User two would have *exactly the same code* except for
>
> "slewis@server.com" would be changed to "li-te_cheng@us.ibm.com"
> and new Chat("slewis") would be changed to "li-te". The Chat object
> code itself would also be the same on both/all participants.
>
> There would be other ways to implement this functionality, but I think
> this is the most straightforward. The basic notion is that the
> ISharedObject is really responsible for implementing all of the 'chat'
> functionality (or presence functionality, or file sharing
> functionality, etc).
>
> Some more comments are interspersed below:
>
> <code deleted>
>
>> --- for user 2
>>
>> // similar process like user 1 (log into a chat lobby) and
>> // then in the chatLobby listener defined by calling
>> // chatLobby.addListener(), check if an invitation message
>> // came through. the invite should hold chatSessionId so
>> // user 2 can do something like this
>>
>> private void joinSession( ID chatSessionId )
>> {
>> ISharedObjectContainer chatSession =
>> SharedObjectContainerFactory.
>> makeSharedObjectContainer("chatSession");
>>
>> // e.g. join info could might be a password if the chat room is
>> // protected
>> Object joinInfo = ...; // ???
>> chatSession.joinGroup(chatSessionId,joinInfo);
>> }
>>
>>
>> Several notes:
>>
>> In this setup, there is a container for a "lobby", the public space
>> to discover other members. The lobby is where people can send
>> invites, and find out who's online (e.g. buddy list). Shared objects
>> in the lobby are really tokens for user presence : if user1's object
>> is in the lobby, then user1 is "online". Login is done via the
>> join() method. Listing who's online is done by listing what object
>> IDs are in the "lobby" container (after join() is called).
>
>
> Yes.
>
>>
>> The lobby needs a unique ID for all users to connect to. This is
>> done by defining an ID via namespaces. IDFactory.getNamespace(...)
>> would define an appropriate namespace for IDFactory.makeID(...)
>
>
> Yes.
>
>>
>> To start a chat, user1 creates another container for the 1-to-1 chat
>> session. join() here denotes creating a session for 1-to-1 access,
>> so a lot of this hinges upon the Object[] parameter in join()... this
>> doesn't feel quite right to me.
>
>
> As my example above shows, this isn't strictly necessary. There's no
> reason to have the container create a new container for this simple
> chat case. To implement a 'multiple chat groups with a lobby chat'
> sort of approach it might be helpful to define new containers to
> represent other chat groups, but it's not necessary for this simple chat
>
>>
>> To invite user2, user1 sends a message to user2 in the lobby
>> container via a ISharedObjectContext... not sure how to get one of
>> these context objects. I don't see a ISharedObject.getContext()
>> method.
>
>
> It's on the ISharedObjectConfig that is passed to the shared object
> via the 'init' method. ISharedObjectConfig.getContext(). This is
> explicitly modelled after the ServletConfig/ServletContext relationship.
>
> /And
>
>> ISharedContainerObject.getConfig() doesn't return a
>> ISharedObjectConfig which has the needed getContext() method.
>
>
> No, the ISharedObjectContainer.getConfig() is the config associated
> with the container (not the config associated with the ISharedObject).
>
>>
>> user2 would have to set up a listener in the lobby container for
>> invitation message types, and join the 1-to-1 chat session container
>> by calling join(). The ID of the chat session must be passed along
>> in the invitation message.
>>
>> Does this sound right?
>
>
> Well yes, except that I would put most of what you are describing for
> invitation messages and etc in the implementation of the Chat class.
> The chat class I've provided simply sends around nickname/message
> pairs...but an invitation message could easily also be
> defined/responded to within the Chat class itself as you describe.
>
> Hopefully this helps.
>
> Scott
>
>>
>> Li-Te
>>
>>
>> John F. Patterson wrote:
>>
>>> It would help me if we identified a few use cases and worked them
>>> through using the API. The simplest is probably starting a chat.
>>> We can worry later about actually using the chat. For now, I just
>>> want to understand how it all gets started.
>>>
>>> Normally, I think of chat as having three main steps to get it going:
>>>
>>> 1. One user initiates a chat session.
>>> 2. Somehow another user becomes informed of the existence of the chat
>>> (the invite)
>>> 3. The second user joins the chat.
>>>
>>> For step 1), I assume that I create a SharedContainer to correspond
>>> to the chat session. Then I create a SharedObject that will be used
>>> to accomplish the actual communication.
>>> For step 2), I assume I must send the ID of the SharedContainer to
>>> the other user. I don't believe the ECF provides an explicit way to
>>> do this, but one could be invented on top of it.
>>> For step 3), I assume the second user creates a SharedContainer of
>>> the appropriate type (how do they know the type?) and Join the group
>>> identified by the ID sent to them. Then somehow, they find the
>>> SharedObject.
>>>
>>> Do I have this right, as far as it goes? As you can see, I am a
>>> little unclear on some of the specifics, particularly on how the
>>> SharedObjects come to exist on the second machine. Are they brought
>>> into existence upon joining the group? Does the second user learn
>>> about them via an event?
>>>
>>> I would find it helpful to see the code for this use case.
>>
>
> ------------------------------------------------------------ ------------
>
>package org.eclipse.ecf.test.ui.actions;
>
>import java.io.IOException;
>
>import org.eclipse.ecf.core.ISharedObject;
>import org.eclipse.ecf.core.ISharedObjectConfig;
>import org.eclipse.ecf.core.ISharedObjectContext;
>import org.eclipse.ecf.core.SharedObjectInitException;
>import org.eclipse.ecf.core.events.RemoteSharedObjectEvent;
>import org.eclipse.ecf.core.identity.ID;
>import org.eclipse.ecf.core.util.Event;
>
>public class Chat implements ISharedObject {
>
> public Chat(String nickname) {
> super();
> }
>
> String nickname;
> ISharedObjectConfig config;
>
> public void init(ISharedObjectConfig initData)
> throws SharedObjectInitException {
> this.config = initData;
> }
>
> public ID getID() {
> if (config == null) return null;
> else return config.getSharedObjectID();
> }
>
> public void handleEvent(Event event) {
> // This is the code to handle a
> if (event instanceof RemoteSharedObjectEvent) {
> // We've got an instance of event sent by remote
> // We'll assume it's a chat message
> RemoteSharedObjectEvent chatEvent = (RemoteSharedObjectEvent) event;
> handleChatEvent(chatEvent);
> } else System.out.println("ID: "+getID().getName()+" got unknown event: "+event);
> }
>
> protected void handleChatEvent(RemoteSharedObjectEvent chatEvent) {
> // It's actually an object array...see sendChatToRemote
> Object [] data = (Object []) chatEvent.getData();
> showChatToUI((String) data[0], (String) data[1]);
> }
> protected void showChatToUI(String senderNickname, String message) {
> System.out.println("Received chat message from: "+senderNickname);
> System.out.println("Message: "+message);
> }
>
> // This is method to call to send message to remotes
> protected void sendChatToRemote(String message) {
> ISharedObjectContext ctx = config.getContext();
> Object [] data = new Object[] { nickname, message };
> try {
> // Note that null means to *all* remotes in current container
> ctx.sendMessage(null,data);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> public void handleEvents(Event[] events) {
> for(int i=0; i < events.length; i++) {
> handleEvent(events[i]);
> }
> }
>
> public void dispose(ID containerID) {
> System.out.println("ID:"+getID().getName()+" dispose("+containerID.getName()+")");
> config = null;
> }
>
> public Object getAdapter(Class clazz) {
> System.out.println("ID:"+getID().getName()+" getAdapter("+clazz.getName()+")");
> return null;
> }
>
>}
>
>
--------------080303020306050706080803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I'm confused. You indicate below that one person uses
<a class="moz-txt-link-rfc2396E" href="mailto:slewis@server.com">"slewis@server.com"</a> for the GroupID and the other uses
<a class="moz-txt-link-rfc2396E" href="mailto:li-te_cheng@us.ibm.com">"li-te_cheng@us.ibm.com"</a> for the GroupID. If they don't use the same
GroupID, how do they ever get their local proxies ties together.<br>
<br>
What am I missing?<br>
<br>
Scott Lewis wrote:
<blockquote cite="mid41C0BA29.20803@composent.com" type="cite">Hi Li-Te
and all,
<br>
<br>
Here are some comments on Li-Te's chat application.
<br>
<br>
Li-Te wrote:
<br>
<blockquote type="cite">(note: newsgroup is acting funny .... seeing
double posts. so apologies if this appears twice, or if someone
already answered John's question)
<br>
<br>
Here is my rough understanding of this from what I've read so far in
the javadoc and online documentation. Someone say something in if I'm
wrong here. Putting in "???" in unknown bits.
<br>
<br>
--- for user 1
<br>
<br>
// create a chat container - ignore what kind of protocols, etc for now
<br>
ISharedObjectContainer chatLobby =
<br>
SharedObjectContainerFactory.
<br>
makeSharedObjectContainer("chatLobby");
<br>
</blockquote>
<br>
Yes. This is the first step...to create a container for the chat.
<br>
<br>
In preference to all of the code you have below, I would design things
so that the program would be structured as follows:
<br>
<br>
// join the group...this connects to some server...using any/all
<br>
// authentication required by 'chatLobby'
<br>
chatLobby.joinGroup(IDFactory.makeStringID(<a class="moz-txt-link-rfc2396E" href="mailto:slewis@server.com">"slewis@server.com"</a>,null);
<br>
<br>
// Create an ISharedObject that represents me...i.e. has my nickname
<br>
Chat chat = new Chat("slewis");
<br>
<br>
// And add the shared object to the container...this will init the Chat
<br>
// instance and allow it to start sending/receiving messages
<br>
chatLobby.getSharedObjectManager().addSharedObject(IDFactory .makeStringID( "chat"),chat,new
Properties(),null);
<br>
<br>
For a simple chat, this would be all I would need. All the
functionality of sending/receiving messages would be implemented in the
Chat class. I've attached a copy of the source to this class in this
email, and I'll also be checking it in to the org.eclipse.ecf.test
plugin later today.
<br>
<br>
User two would have *exactly the same code* except for
<br>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:slewis@server.com">"slewis@server.com"</a> would be changed to <a class="moz-txt-link-rfc2396E" href="mailto:li-te_cheng@us.ibm.com">"li-te_cheng@us.ibm.com"</a>
<br>
and new Chat("slewis") would be changed to "li-te". The Chat object
code itself would also be the same on both/all participants.
<br>
<br>
There would be other ways to implement this functionality, but I think
this is the most straightforward. The basic notion is that the
ISharedObject is really responsible for implementing all of the 'chat'
functionality (or presence functionality, or file sharing
functionality, etc).
<br>
<br>
Some more comments are interspersed below:
<br>
<br>
<code deleted>
<br>
<br>
<blockquote type="cite">--- for user 2
<br>
<br>
// similar process like user 1 (log into a chat lobby) and
<br>
// then in the chatLobby listener defined by calling
<br>
// chatLobby.addListener(), check if an invitation message
<br>
// came through. the invite should hold chatSessionId so
<br>
// user 2 can do something like this
<br>
<br>
private void joinSession( ID chatSessionId )
<br>
{
<br>
ISharedObjectContainer chatSession =
<br>
SharedObjectContainerFactory.
<br>
makeSharedObjectContainer("chatSession");
<br>
<br>
// e.g. join info could might be a password if the chat room is
<br>
// protected
<br>
Object joinInfo = ...; // ???
<br>
chatSession.joinGroup(chatSessionId,joinInfo);
<br>
}
<br>
<br>
<br>
Several notes:
<br>
<br>
In this setup, there is a container for a "lobby", the public space to
discover other members. The lobby is where people can send invites,
and find out who's online (e.g. buddy list). Shared objects in the
lobby are really tokens for user presence : if user1's object is in the
lobby, then user1 is "online". Login is done via the join() method.
Listing who's online is done by listing what object IDs are in the
"lobby" container (after join() is called).
<br>
</blockquote>
<br>
Yes.
<br>
<br>
<blockquote type="cite"><br>
The lobby needs a unique ID for all users to connect to. This is done
by defining an ID via namespaces. IDFactory.getNamespace(...) would
define an appropriate namespace for IDFactory.makeID(...)
<br>
</blockquote>
<br>
Yes.
<br>
<br>
<blockquote type="cite"><br>
To start a chat, user1 creates another container for the 1-to-1 chat
session. join() here denotes creating a session for 1-to-1 access, so
a lot of this hinges upon the Object[] parameter in join()... this
doesn't feel quite right to me.
<br>
</blockquote>
<br>
As my example above shows, this isn't strictly necessary. There's no
reason to have the container create a new container for this simple
chat case. To implement a 'multiple chat groups with a lobby chat'
sort of approach it might be helpful to define new containers to
represent other chat groups, but it's not necessary for this simple
chat
<br>
<br>
<blockquote type="cite"><br>
To invite user2, user1 sends a message to user2 in the lobby container
via a ISharedObjectContext... not sure how to get one of these context
objects. I don't see a ISharedObject.getContext() method. </blockquote>
<br>
It's on the ISharedObjectConfig that is passed to the shared object via
the 'init' method. ISharedObjectConfig.getContext(). This is
explicitly modelled after the ServletConfig/ServletContext
relationship.
<br>
<br>
/And
<br>
<blockquote type="cite">ISharedContainerObject.getConfig() doesn't
return a ISharedObjectConfig which has the needed getContext() method.
<br>
</blockquote>
<br>
No, the ISharedObjectContainer.getConfig() is the config associated
with the container (not the config associated with the ISharedObject).
<br>
<br>
<blockquote type="cite"><br>
user2 would have to set up a listener in the lobby container for
invitation message types, and join the 1-to-1 chat session container by
calling join(). The ID of the chat session must be passed along in the
invitation message.
<br>
<br>
Does this sound right?
<br>
</blockquote>
<br>
Well yes, except that I would put most of what you are describing for
invitation messages and etc in the implementation of the Chat class.
The chat class I've provided simply sends around nickname/message
pairs...but an invitation message could easily also be
defined/responded to within the Chat class itself as you describe.
<br>
<br>
Hopefully this helps.
<br>
<br>
Scott
<br>
<br>
<blockquote type="cite"><br>
Li-Te
<br>
<br>
<br>
John F. Patterson wrote:
<br>
<br>
<blockquote type="cite">It would help me if we identified a few use
cases and worked them through using the API. The simplest is probably
starting a chat. We can worry later about actually using the chat.
For now, I just want to understand how it all gets started.
<br>
<br>
Normally, I think of chat as having three main steps to get it going:
<br>
<br>
1. One user initiates a chat session.
<br>
2. Somehow another user becomes informed of the existence of the chat
<br>
(the invite)
<br>
3. The second user joins the chat.
<br>
<br>
For step 1), I assume that I create a SharedContainer to correspond to
the chat session. Then I create a SharedObject that will be used to
accomplish the actual communication.
<br>
For step 2), I assume I must send the ID of the SharedContainer to the
other user. I don't believe the ECF provides an explicit way to do
this, but one could be invented on top of it.
<br>
For step 3), I assume the second user creates a SharedContainer of the
appropriate type (how do they know the type?) and Join the group
identified by the ID sent to them. Then somehow, they find the
SharedObject.
<br>
<br>
Do I have this right, as far as it goes? As you can see, I am a little
unclear on some of the specifics, particularly on how the SharedObjects
come to exist on the second machine. Are they brought into existence
upon joining the group? Does the second user learn about them via an
event?
<br>
<br>
I would find it helpful to see the code for this use case.
<br>
</blockquote>
</blockquote>
<br>
<pre wrap="">
<hr size="4" width="90%">
package org.eclipse.ecf.test.ui.actions;
import java.io.IOException;
import org.eclipse.ecf.core.ISharedObject;
import org.eclipse.ecf.core.ISharedObjectConfig;
import org.eclipse.ecf.core.ISharedObjectContext;
import org.eclipse.ecf.core.SharedObjectInitException;
import org.eclipse.ecf.core.events.RemoteSharedObjectEvent;
import org.eclipse.ecf.core.identity.ID;
import org.eclipse.ecf.core.util.Event;
public class Chat implements ISharedObject {
public Chat(String nickname) {
super();
}
String nickname;
ISharedObjectConfig config;
public void init(ISharedObjectConfig initData)
throws SharedObjectInitException {
this.config = initData;
}
public ID getID() {
if (config == null) return null;
else return config.getSharedObjectID();
}
public void handleEvent(Event event) {
// This is the code to handle a
if (event instanceof RemoteSharedObjectEvent) {
// We've got an instance of event sent by remote
// We'll assume it's a chat message
RemoteSharedObjectEvent chatEvent = (RemoteSharedObjectEvent) event;
handleChatEvent(chatEvent);
} else System.out.println("ID: "+getID().getName()+" got unknown event: "+event);
}
protected void handleChatEvent(RemoteSharedObjectEvent chatEvent) {
// It's actually an object array...see sendChatToRemote
Object [] data = (Object []) chatEvent.getData();
showChatToUI((String) data[0], (String) data[1]);
}
protected void showChatToUI(String senderNickname, String message) {
System.out.println("Received chat message from: "+senderNickname);
System.out.println("Message: "+message);
}
// This is method to call to send message to remotes
protected void sendChatToRemote(String message) {
ISharedObjectContext ctx = config.getContext();
Object [] data = new Object[] { nickname, message };
try {
// Note that null means to *all* remotes in current container
ctx.sendMessage(null,data);
} catch (IOException e) {
e.printStackTrace();
}
}
public void handleEvents(Event[] events) {
for(int i=0; i < events.length; i++) {
handleEvent(events[i]);
}
}
public void dispose(ID containerID) {
System.out.println("ID:"+getID().getName()+" dispose("+containerID.getName()+")");
config = null;
}
public Object getAdapter(Class clazz) {
System.out.println("ID:"+getID().getName()+" getAdapter("+clazz.getName()+")");
return null;
}
}
</pre>
</blockquote>
</body>
</html>
--------------080303020306050706080803--
|
|
|
| Re: Don't the Group IDs need to be the same? [message #570914 is a reply to message #570882] |
Thu, 16 December 2004 19:49 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi John,
John F. Patterson wrote:
> I'm confused. You indicate below that one person uses
> "slewis@server.com" for the GroupID and the other uses
> "li-te_cheng@us.ibm.com" for the GroupID. If they don't use the same
> GroupID, how do they ever get their local proxies ties together.
>
> What am I missing?
My mistake. What I meant was that the two addresses would have to be
something like:
"slewis@server.com"
and "li-te_cheng@server.com"
assuming that "server.com" was the host of the group (on a known port).
If, for a given provider, other info was necessary, things might look
like this:
https://server.com:4444/mygroup
or sip://<whatever sip further requires to identify a session>
or jabber:slewis@jabber.com/group1
In general, the syntax of the ID for joinging a group is going to be
specific to the provider type. Depending upon the provider
implementation, it may even be a provider-specific ID type (i.e. define
a new ID type just for the given provider.
Thanks for pointing out this error.
Scott
>
> Scott Lewis wrote:
>
>> Hi Li-Te and all,
>>
>> Here are some comments on Li-Te's chat application.
>>
>> Li-Te wrote:
>>
>>> (note: newsgroup is acting funny .... seeing double posts. so
>>> apologies if this appears twice, or if someone already answered
>>> John's question)
>>>
>>> Here is my rough understanding of this from what I've read so far in
>>> the javadoc and online documentation. Someone say something in if
>>> I'm wrong here. Putting in "???" in unknown bits.
>>>
>>> --- for user 1
>>>
>>> // create a chat container - ignore what kind of protocols, etc for now
>>> ISharedObjectContainer chatLobby =
>>> SharedObjectContainerFactory.
>>> makeSharedObjectContainer("chatLobby");
>>
>>
>> Yes. This is the first step...to create a container for the chat.
>>
>> In preference to all of the code you have below, I would design things
>> so that the program would be structured as follows:
>>
>> // join the group...this connects to some server...using any/all
>> // authentication required by 'chatLobby'
>> chatLobby.joinGroup(IDFactory.makeStringID("slewis@server.com",null);
>>
>> // Create an ISharedObject that represents me...i.e. has my nickname
>> Chat chat = new Chat("slewis");
>>
>> // And add the shared object to the container...this will init the Chat
>> // instance and allow it to start sending/receiving messages
>> chatLobby.getSharedObjectManager().addSharedObject(IDFactory .makeStringID( "chat"),chat,new
>> Properties(),null);
>>
>> For a simple chat, this would be all I would need. All the
>> functionality of sending/receiving messages would be implemented in
>> the Chat class. I've attached a copy of the source to this class in
>> this email, and I'll also be checking it in to the
>> org.eclipse.ecf.test plugin later today.
>>
>> User two would have *exactly the same code* except for
>>
>> "slewis@server.com" would be changed to "li-te_cheng@us.ibm.com"
>> and new Chat("slewis") would be changed to "li-te". The Chat object
>> code itself would also be the same on both/all participants.
>>
>> There would be other ways to implement this functionality, but I think
>> this is the most straightforward. The basic notion is that the
>> ISharedObject is really responsible for implementing all of the 'chat'
>> functionality (or presence functionality, or file sharing
>> functionality, etc).
>>
>> Some more comments are interspersed below:
>>
>> <code deleted>
>>
>>> --- for user 2
>>>
>>> // similar process like user 1 (log into a chat lobby) and
>>> // then in the chatLobby listener defined by calling
>>> // chatLobby.addListener(), check if an invitation message
>>> // came through. the invite should hold chatSessionId so
>>> // user 2 can do something like this
>>>
>>> private void joinSession( ID chatSessionId )
>>> {
>>> ISharedObjectContainer chatSession =
>>> SharedObjectContainerFactory.
>>> makeSharedObjectContainer("chatSession");
>>>
>>> // e.g. join info could might be a password if the chat room is
>>> // protected
>>> Object joinInfo = ...; // ???
>>> chatSession.joinGroup(chatSessionId,joinInfo);
>>> }
>>>
>>>
>>> Several notes:
>>>
>>> In this setup, there is a container for a "lobby", the public space
>>> to discover other members. The lobby is where people can send
>>> invites, and find out who's online (e.g. buddy list). Shared objects
>>> in the lobby are really tokens for user presence : if user1's object
>>> is in the lobby, then user1 is "online". Login is done via the
>>> join() method. Listing who's online is done by listing what object
>>> IDs are in the "lobby" container (after join() is called).
>>
>>
>> Yes.
>>
>>>
>>> The lobby needs a unique ID for all users to connect to. This is
>>> done by defining an ID via namespaces. IDFactory.getNamespace(...)
>>> would define an appropriate namespace for IDFactory.makeID(...)
>>
>>
>> Yes.
>>
>>>
>>> To start a chat, user1 creates another container for the 1-to-1 chat
>>> session. join() here denotes creating a session for 1-to-1 access,
>>> so a lot of this hinges upon the Object[] parameter in join()... this
>>> doesn't feel quite right to me.
>>
>>
>> As my example above shows, this isn't strictly necessary. There's no
>> reason to have the container create a new container for this simple
>> chat case. To implement a 'multiple chat groups with a lobby chat'
>> sort of approach it might be helpful to define new containers to
>> represent other chat groups, but it's not necessary for this simple chat
>>
>>>
>>> To invite user2, user1 sends a message to user2 in the lobby
>>> container via a ISharedObjectContext... not sure how to get one of
>>> these context objects. I don't see a ISharedObject.getContext()
>>> method.
>>
>>
>> It's on the ISharedObjectConfig that is passed to the shared object
>> via the 'init' method. ISharedObjectConfig.getContext(). This is
>> explicitly modelled after the ServletConfig/ServletContext relationship.
>>
>> /And
>>
>>> ISharedContainerObject.getConfig() doesn't return a
>>> ISharedObjectConfig which has the needed getContext() method.
>>
>>
>> No, the ISharedObjectContainer.getConfig() is the config associated
>> with the container (not the config associated with the ISharedObject).
>>
>>>
>>> user2 would have to set up a listener in the lobby container for
>>> invitation message types, and join the 1-to-1 chat session container
>>> by calling join(). The ID of the chat session must be passed along
>>> in the invitation message.
>>>
>>> Does this sound right?
>>
>>
>> Well yes, except that I would put most of what you are describing for
>> invitation messages and etc in the implementation of the Chat class.
>> The chat class I've provided simply sends around nickname/message
>> pairs...but an invitation message could easily also be
>> defined/responded to within the Chat class itself as you describe.
>>
>> Hopefully this helps.
>>
>> Scott
>>
>>>
>>> Li-Te
>>>
>>>
>>> John F. Patterson wrote:
>>>
>>>> It would help me if we identified a few use cases and worked them
>>>> through using the API. The simplest is probably starting a chat.
>>>> We can worry later about actually using the chat. For now, I just
>>>> want to understand how it all gets started.
>>>>
>>>> Normally, I think of chat as having three main steps to get it going:
>>>>
>>>> 1. One user initiates a chat session.
>>>> 2. Somehow another user becomes informed of the existence of the chat
>>>> (the invite)
>>>> 3. The second user joins the chat.
>>>>
>>>> For step 1), I assume that I create a SharedContainer to correspond
>>>> to the chat session. Then I create a SharedObject that will be used
>>>> to accomplish the actual communication.
>>>> For step 2), I assume I must send the ID of the SharedContainer to
>>>> the other user. I don't believe the ECF provides an explicit way to
>>>> do this, but one could be invented on top of it.
>>>> For step 3), I assume the second user creates a SharedContainer of
>>>> the appropriate type (how do they know the type?) and Join the group
>>>> identified by the ID sent to them. Then somehow, they find the
>>>> SharedObject.
>>>>
>>>> Do I have this right, as far as it goes? As you can see, I am a
>>>> little unclear on some of the specifics, particularly on how the
>>>> SharedObjects come to exist on the second machine. Are they brought
>>>> into existence upon joining the group? Does the second user learn
>>>> about them via an event?
>>>>
>>>> I would find it helpful to see the code for this use case.
>>>
>>
>> ------------------------------------------------------------ ------------
>>
>>package org.eclipse.ecf.test.ui.actions;
>>
>>import java.io.IOException;
>>
>>import org.eclipse.ecf.core.ISharedObject;
>>import org.eclipse.ecf.core.ISharedObjectConfig;
>>import org.eclipse.ecf.core.ISharedObjectContext;
>>import org.eclipse.ecf.core.SharedObjectInitException;
>>import org.eclipse.ecf.core.events.RemoteSharedObjectEvent;
>>import org.eclipse.ecf.core.identity.ID;
>>import org.eclipse.ecf.core.util.Event;
>>
>>public class Chat implements ISharedObject {
>>
>> public Chat(String nickname) {
>> super();
>> }
>>
>> String nickname;
>> ISharedObjectConfig config;
>>
>> public void init(ISharedObjectConfig initData)
>> throws SharedObjectInitException {
>> this.config = initData;
>> }
>>
>> public ID getID() {
>> if (config == null) return null;
>> else return config.getSharedObjectID();
>> }
>>
>> public void handleEvent(Event event) {
>> // This is the code to handle a
>> if (event instanceof RemoteSharedObjectEvent) {
>> // We've got an instance of event sent by remote
>> // We'll assume it's a chat message
>> RemoteSharedObjectEvent chatEvent = (RemoteSharedObjectEvent) event;
>> handleChatEvent(chatEvent);
>> } else System.out.println("ID: "+getID().getName()+" got unknown event: "+event);
>> }
>>
>> protected void handleChatEvent(RemoteSharedObjectEvent chatEvent) {
>> // It's actually an object array...see sendChatToRemote
>> Object [] data = (Object []) chatEvent.getData();
>> showChatToUI((String) data[0], (String) data[1]);
>> }
>> protected void showChatToUI(String senderNickname, String message) {
>> System.out.println("Received chat message from: "+senderNickname);
>> System.out.println("Message: "+message);
>> }
>>
>> // This is method to call to send message to remotes
>> protected void sendChatToRemote(String message) {
>> ISharedObjectContext ctx = config.getContext();
>> Object [] data = new Object[] { nickname, message };
>> try {
>> // Note that null means to *all* remotes in current container
>> ctx.sendMessage(null,data);
>> } catch (IOException e) {
>> e.printStackTrace();
>> }
>> }
>> public void handleEvents(Event[] events) {
>> for(int i=0; i < events.length; i++) {
>> handleEvent(events[i]);
>> }
>> }
>>
>> public void dispose(ID containerID) {
>> System.out.println("ID:"+getID().getName()+" dispose("+containerID.getName()+")");
>> config = null;
>> }
>>
>> public Object getAdapter(Class clazz) {
>> System.out.println("ID:"+getID().getName()+" getAdapter("+clazz.getName()+")");
>> return null;
>> }
>>
>>}
>>
>>
|
|
|
| You seem to equate the container with the server rather than a meeting [message #570986 is a reply to message #570914] |
Sat, 18 December 2004 21:56 |
| Eclipse User |
|
|
|
Originally posted by: john_patterson.us.ibm.com
Scott:
This still surprises me, but it is clarifying. You seem to equate the
container with the server, or the rendezvous point, rather than with a
meeting, or mutlipoint communication context.
Is that correct?
Li-Te's original answer to my question was more like what I expected
because I was treating a chat as an instance of an eMeeting rather than
an IM. You are right that there is a simpler form for simple 2-person
chats. Your answer still begs the question, however. Suppose we wanted
a multi-way chat or a chatRoom, how would we do it in ECF? I usually
expect the server to act as a rendezvous point off of which we might
have several meetings. Are these meetings containers also, or are they
a special form of SharedObject.
jfp
Scott Lewis wrote:
> Hi John,
>
> John F. Patterson wrote:
>
>> I'm confused. You indicate below that one person uses
>> "slewis@server.com" for the GroupID and the other uses
>> "li-te_cheng@us.ibm.com" for the GroupID. If they don't use the same
>> GroupID, how do they ever get their local proxies ties together.
>>
>> What am I missing?
>
>
> My mistake. What I meant was that the two addresses would have to be
> something like:
>
> "slewis@server.com"
>
> and "li-te_cheng@server.com"
>
> assuming that "server.com" was the host of the group (on a known port).
>
> If, for a given provider, other info was necessary, things might look
> like this:
>
> https://server.com:4444/mygroup
> or sip://<whatever sip further requires to identify a session>
> or jabber:slewis@jabber.com/group1
>
> In general, the syntax of the ID for joinging a group is going to be
> specific to the provider type. Depending upon the provider
> implementation, it may even be a provider-specific ID type (i.e.
> define a new ID type just for the given provider.
>
> Thanks for pointing out this error.
>
> Scott
>
[stuff deleted]
|
|
|
| Re: You seem to equate the container with the server rather than a meeting [message #571009 is a reply to message #570986] |
Sun, 19 December 2004 01:06 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi John,
John F. Patterson wrote:
> Scott:
>
> This still surprises me, but it is clarifying. You seem to equate the
> container with the server, or the rendezvous point, rather than with a
> meeting, or mutlipoint communication context.
> Is that correct?
The notion is that the container represents access to a distributed
group. This can be server-provided or not...and for conferencing or
not...it's just defined as a group of processes that are communicating
with one another for some reason (app) or another.
>
> Li-Te's original answer to my question was more like what I expected
> because I was treating a chat as an instance of an eMeeting rather than
> an IM.
The Chat object I provided delivers an N-way chat...assuming that
'server.com' and the associated provider deliver that functionality.
>You are right that there is a simpler form for simple 2-person
> chats.
Like I said, the Chat object is not just a simple two-person
chat...except in the case where the underlying provider only supports a
1-1 situation (e.g. some IM protocols).
>Your answer still begs the question, however. Suppose we wanted
> a multi-way chat or a chatRoom, how would we do it in ECF?
As per the Chat object.
>I usually
> expect the server to act as a rendezvous point off of which we might
> have several meetings.
Sure...that's the role played by 'server.com' in the example.
>Are these meetings containers also, or are they
> a special form of SharedObject.
The containers define the connectivity between processes. Some
containers can only support communication via 1-1 chats. Other (most)
providers are going to support a full n-way group. The shared objects
define the communications functionality between the processes.
There can be more than one object per container (i.e. different apps
running on same comm system), and more than one comm system for a given
app (i.e. using jabber and yahoo and SIP for a single application).
Scott
>
> jfp
>
> Scott Lewis wrote:
>
>> Hi John,
>>
>> John F. Patterson wrote:
>>
>>> I'm confused. You indicate below that one person uses
>>> "slewis@server.com" for the GroupID and the other uses
>>> "li-te_cheng@us.ibm.com" for the GroupID. If they don't use the same
>>> GroupID, how do they ever get their local proxies ties together.
>>>
>>> What am I missing?
>>
>>
>>
>> My mistake. What I meant was that the two addresses would have to be
>> something like:
>>
>> "slewis@server.com"
>>
>> and "li-te_cheng@server.com"
>>
>> assuming that "server.com" was the host of the group (on a known port).
>>
>> If, for a given provider, other info was necessary, things might look
>> like this:
>>
>> https://server.com:4444/mygroup
>> or sip://<whatever sip further requires to identify a session>
>> or jabber:slewis@jabber.com/group1
>>
>> In general, the syntax of the ID for joinging a group is going to be
>> specific to the provider type. Depending upon the provider
>> implementation, it may even be a provider-specific ID type (i.e.
>> define a new ID type just for the given provider.
>>
>> Thanks for pointing out this error.
>>
>> Scott
>>
> [stuff deleted]
|
|
|
| How do SharedObjects become known on the remote systems [message #571068 is a reply to message #570783] |
Sun, 19 December 2004 07:03 |
| Eclipse User |
|
|
|
Originally posted by: john_patterson.us.ibm.com
This is a multi-part message in MIME format.
--------------000802090402060501040501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
In this analysis, I assume I send to Li-Te by performing a send on his
chat object and he sends to me by performing a send on my chat object.
Is this correct? Li-Te seemed to believe a connector would be needed,
but that does not appear to be correct. Am I right on this?
How does a remote system come to "know" about SharedObjects created by
someone else? I assume the SharedObject is not automatically created.
Do I learn of the ID in a listener on the Container? Will I learn of
the type as well, so that I will know what sort of object needs to be
created?
jfp
Scott Lewis wrote:
> Hi Li-Te and all,
>
> Here are some comments on Li-Te's chat application.
>
> Li-Te wrote:
>
>> (note: newsgroup is acting funny .... seeing double posts. so
>> apologies if this appears twice, or if someone already answered
>> John's question)
>>
>> Here is my rough understanding of this from what I've read so far in
>> the javadoc and online documentation. Someone say something in if
>> I'm wrong here. Putting in "???" in unknown bits.
>>
>> --- for user 1
>>
>> // create a chat container - ignore what kind of protocols, etc for now
>> ISharedObjectContainer chatLobby =
>> SharedObjectContainerFactory.
>> makeSharedObjectContainer("chatLobby");
>
>
> Yes. This is the first step...to create a container for the chat.
>
> In preference to all of the code you have below, I would design things
> so that the program would be structured as follows:
>
> // join the group...this connects to some server...using any/all
> // authentication required by 'chatLobby'
> chatLobby.joinGroup(IDFactory.makeStringID("slewis@server.com",null);
>
> // Create an ISharedObject that represents me...i.e. has my nickname
> Chat chat = new Chat("slewis");
>
> // And add the shared object to the container...this will init the Chat
> // instance and allow it to start sending/receiving messages
> chatLobby.getSharedObjectManager().addSharedObject(IDFactory .makeStringID( "chat"),chat,new
> Properties(),null);
>
> For a simple chat, this would be all I would need. All the
> functionality of sending/receiving messages would be implemented in
> the Chat class. I've attached a copy of the source to this class in
> this email, and I'll also be checking it in to the
> org.eclipse.ecf.test plugin later today.
>
> User two would have *exactly the same code* except for
>
> "slewis@server.com" would be changed to "li-te_cheng@us.ibm.com"
> and new Chat("slewis") would be changed to "li-te". The Chat object
> code itself would also be the same on both/all participants.
>
> There would be other ways to implement this functionality, but I think
> this is the most straightforward. The basic notion is that the
> ISharedObject is really responsible for implementing all of the 'chat'
> functionality (or presence functionality, or file sharing
> functionality, etc).
>
> Some more comments are interspersed below:
>
> <code deleted>
>
>> --- for user 2
>>
>> // similar process like user 1 (log into a chat lobby) and
>> // then in the chatLobby listener defined by calling
>> // chatLobby.addListener(), check if an invitation message
>> // came through. the invite should hold chatSessionId so
>> // user 2 can do something like this
>>
>> private void joinSession( ID chatSessionId )
>> {
>> ISharedObjectContainer chatSession =
>> SharedObjectContainerFactory.
>> makeSharedObjectContainer("chatSession");
>>
>> // e.g. join info could might be a password if the chat room is
>> // protected
>> Object joinInfo = ...; // ???
>> chatSession.joinGroup(chatSessionId,joinInfo);
>> }
>>
>>
>> Several notes:
>>
>> In this setup, there is a container for a "lobby", the public space
>> to discover other members. The lobby is where people can send
>> invites, and find out who's online (e.g. buddy list). Shared objects
>> in the lobby are really tokens for user presence : if user1's object
>> is in the lobby, then user1 is "online". Login is done via the
>> join() method. Listing who's online is done by listing what object
>> IDs are in the "lobby" container (after join() is called).
>
>
> Yes.
>
>>
>> The lobby needs a unique ID for all users to connect to. This is
>> done by defining an ID via namespaces. IDFactory.getNamespace(...)
>> would define an appropriate namespace for IDFactory.makeID(...)
>
>
> Yes.
>
>>
>> To start a chat, user1 creates another container for the 1-to-1 chat
>> session. join() here denotes creating a session for 1-to-1 access,
>> so a lot of this hinges upon the Object[] parameter in join()... this
>> doesn't feel quite right to me.
>
>
> As my example above shows, this isn't strictly necessary. There's no
> reason to have the container create a new container for this simple
> chat case. To implement a 'multiple chat groups with a lobby chat'
> sort of approach it might be helpful to define new containers to
> represent other chat groups, but it's not necessary for this simple chat
>
>>
>> To invite user2, user1 sends a message to user2 in the lobby
>> container via a ISharedObjectContext... not sure how to get one of
>> these context objects. I don't see a ISharedObject.getContext()
>> method.
>
>
> It's on the ISharedObjectConfig that is passed to the shared object
> via the 'init' method. ISharedObjectConfig.getContext(). This is
> explicitly modelled after the ServletConfig/ServletContext relationship.
>
> /And
>
>> ISharedContainerObject.getConfig() doesn't return a
>> ISharedObjectConfig which has the needed getContext() method.
>
>
> No, the ISharedObjectContainer.getConfig() is the config associated
> with the container (not the config associated with the ISharedObject).
>
>>
>> user2 would have to set up a listener in the lobby container for
>> invitation message types, and join the 1-to-1 chat session container
>> by calling join(). The ID of the chat session must be passed along
>> in the invitation message.
>>
>> Does this sound right?
>
>
> Well yes, except that I would put most of what you are describing for
> invitation messages and etc in the implementation of the Chat class.
> The chat class I've provided simply sends around nickname/message
> pairs...but an invitation message could easily also be
> defined/responded to within the Chat class itself as you describe.
>
> Hopefully this helps.
>
> Scott
>
>>
>> Li-Te
>>
>>
>> John F. Patterson wrote:
>>
>>> It would help me if we identified a few use cases and worked them
>>> through using the API. The simplest is probably starting a chat.
>>> We can worry later about actually using the chat. For now, I just
>>> want to understand how it all gets started.
>>>
>>> Normally, I think of chat as having three main steps to get it going:
>>>
>>> 1. One user initiates a chat session.
>>> 2. Somehow another user becomes informed of the existence of the chat
>>> (the invite)
>>> 3. The second user joins the chat.
>>>
>>> For step 1), I assume that I create a SharedContainer to correspond
>>> to the chat session. Then I create a SharedObject that will be used
>>> to accomplish the actual communication.
>>> For step 2), I assume I must send the ID of the SharedContainer to
>>> the other user. I don't believe the ECF provides an explicit way to
>>> do this, but one could be invented on top of it.
>>> For step 3), I assume the second user creates a SharedContainer of
>>> the appropriate type (how do they know the type?) and Join the group
>>> identified by the ID sent to them. Then somehow, they find the
>>> SharedObject.
>>>
>>> Do I have this right, as far as it goes? As you can see, I am a
>>> little unclear on some of the specifics, particularly on how the
>>> SharedObjects come to exist on the second machine. Are they brought
>>> into existence upon joining the group? Does the second user learn
>>> about them via an event?
>>>
>>> I would find it helpful to see the code for this use case.
>>
>
> ------------------------------------------------------------ ------------
>
>package org.eclipse.ecf.test.ui.actions;
>
>import java.io.IOException;
>
>import org.eclipse.ecf.core.ISharedObject;
>import org.eclipse.ecf.core.ISharedObjectConfig;
>import org.eclipse.ecf.core.ISharedObjectContext;
>import org.eclipse.ecf.core.SharedObjectInitException;
>import org.eclipse.ecf.core.events.RemoteSharedObjectEvent;
>import org.eclipse.ecf.core.identity.ID;
>import org.eclipse.ecf.core.util.Event;
>
>public class Chat implements ISharedObject {
>
> public Chat(String nickname) {
> super();
> }
>
> String nickname;
> ISharedObjectConfig config;
>
> public void init(ISharedObjectConfig initData)
> throws SharedObjectInitException {
> this.config = initData;
> }
>
> public ID getID() {
> if (config == null) return null;
> else return config.getSharedObjectID();
> }
>
> public void handleEvent(Event event) {
> // This is the code to handle a
> if (event instanceof RemoteSharedObjectEvent) {
> // We've got an instance of event sent by remote
> // We'll assume it's a chat message
> RemoteSharedObjectEvent chatEvent = (RemoteSharedObjectEvent) event;
> handleChatEvent(chatEvent);
> } else System.out.println("ID: "+getID().getName()+" got unknown event: "+event);
> }
>
> protected void handleChatEvent(RemoteSharedObjectEvent chatEvent) {
> // It's actually an object array...see sendChatToRemote
> Object [] data = (Object []) chatEvent.getData();
> showChatToUI((String) data[0], (String) data[1]);
> }
> protected void showChatToUI(String senderNickname, String message) {
> System.out.println("Received chat message from: "+senderNickname);
> System.out.println("Message: "+message);
> }
>
> // This is method to call to send message to remotes
> protected void sendChatToRemote(String message) {
> ISharedObjectContext ctx = config.getContext();
> Object [] data = new Object[] { nickname, message };
> try {
> // Note that null means to *all* remotes in current container
> ctx.sendMessage(null,data);
> } catch (IOException e) {
> e.printStackTrace();
> }
> }
> public void handleEvents(Event[] events) {
> for(int i=0; i < events.length; i++) {
> handleEvent(events[i]);
> }
> }
>
> public void dispose(ID containerID) {
> System.out.println("ID:"+getID().getName()+" dispose("+containerID.getName()+")");
> config = null;
> }
>
> public Object getAdapter(Class clazz) {
> System.out.println("ID:"+getID().getName()+" getAdapter("+clazz.getName()+")");
> return null;
> }
>
>}
>
>
--------------000802090402060501040501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
In this analysis, I assume I send to Li-Te by performing a send on his
chat object and he sends to me by performing a send on my chat object.
Is this correct? Li-Te seemed to believe a connector would be needed,
but that does not appear to be correct. Am I right on this?<br>
<br>
How does a remote system come to "know" about SharedObjects created by
someone else? I assume the SharedObject is not automatically created.
Do I learn of the ID in a listener on the Container? Will I learn of
the type as well, so that I will know what sort of object needs to be
created?<br>
<br>
jfp<br>
<br>
Scott Lewis wrote:
<blockquote cite="mid41C0BA29.20803@composent.com" type="cite">Hi Li-Te
and all,
<br>
<br>
Here are some comments on Li-Te's chat application.
<br>
<br>
Li-Te wrote:
<br>
<blockquote type="cite">(note: newsgroup is acting funny .... seeing
double posts. so apologies if this appears twice, or if someone
already answered John's question)
<br>
<br>
Here is my rough understanding of this from what I've read so far in
the javadoc and online documentation. Someone say something in if I'm
wrong here. Putting in "???" in unknown bits.
<br>
<br>
--- for user 1
<br>
<br>
// create a chat container - ignore what kind of protocols, etc for now
<br>
ISharedObjectContainer chatLobby =
<br>
SharedObjectContainerFactory.
<br>
makeSharedObjectContainer("chatLobby");
<br>
</blockquote>
<br>
Yes. This is the first step...to create a container for the chat.
<br>
<br>
In preference to all of the code you have below, I would design things
so that the program would be structured as follows:
<br>
<br>
// join the group...this connects to some server...using any/all
<br>
// authentication required by 'chatLobby'
<br>
chatLobby.joinGroup(IDFactory.makeStringID(<a class="moz-txt-link-rfc2396E" href="mailto:slewis@server.com">"slewis@server.com"</a>,null);
<br>
<br>
// Create an ISharedObject that represents me...i.e. has my nickname
<br>
Chat chat = new Chat("slewis");
<br>
<br>
// And add the shared object to the container...this will init the Chat
<br>
// instance and allow it to start sending/receiving messages
<br>
chatLobby.getSharedObjectManager().addSharedObject(IDFactory .makeStringID( "chat"),chat,new
Properties(),null);
<br>
<br>
For a simple chat, this would be all I would need. All the
functionality of sending/receiving messages would be implemented in the
Chat class. I've attached a copy of the source to this class in this
email, and I'll also be checking it in to the org.eclipse.ecf.test
plugin later today.
<br>
<br>
User two would have *exactly the same code* except for
<br>
<br>
<a class="moz-txt-link-rfc2396E" href="mailto:slewis@server.com">"slewis@server.com"</a> would be changed to <a class="moz-txt-link-rfc2396E" href="mailto:li-te_cheng@us.ibm.com">"li-te_cheng@us.ibm.com"</a>
<br>
and new Chat("slewis") would be changed to "li-te". The Chat object
code itself would also be the same on both/all participants.
<br>
<br>
There would be other ways to implement this functionality, but I think
this is the most straightforward. The basic notion is that the
ISharedObject is really responsible for implementing all of the 'chat'
functionality (or presence functionality, or file sharing
functionality, etc).
<br>
<br>
Some more comments are interspersed below:
<br>
<br>
<code deleted>
<br>
<br>
<blockquote type="cite">--- for user 2
<br>
<br>
// similar process like user 1 (log into a chat lobby) and
<br>
// then in the chatLobby listener defined by calling
<br>
// chatLobby.addListener(), check if an invitation message
<br>
// came through. the invite should hold chatSessionId so
<br>
// user 2 can do something like this
<br>
<br>
private void joinSession( ID chatSessionId )
<br>
{
<br>
ISharedObjectContainer chatSession =
<br>
SharedObjectContainerFactory.
<br>
makeSharedObjectContainer("chatSession");
<br>
<br>
// e.g. join info could might be a password if the chat room is
<br>
// protected
<br>
Object joinInfo = ...; // ???
<br>
chatSession.joinGroup(chatSessionId,joinInfo);
<br>
}
<br>
<br>
<br>
Several notes:
<br>
<br>
In this setup, there is a container for a "lobby", the public space to
discover other members. The lobby is where people can send invites,
and find out who's online (e.g. buddy list). Shared objects in the
lobby are really tokens for user presence : if user1's object is in the
lobby, then user1 is "online". Login is done via the join() method.
Listing who's online is done by listing what object IDs are in the
"lobby" container (after join() is called).
<br>
</blockquote>
<br>
Yes.
<br>
<br>
<blockquote type="cite"><br>
The lobby needs a unique ID for all users to connect to. This is done
by defining an ID via namespaces. IDFactory.getNamespace(...) would
define an appropriate namespace for IDFactory.makeID(...)
<br>
</blockquote>
<br>
Yes.
<br>
<br>
<blockquote type="cite"><br>
To start a chat, user1 creates another container for the 1-to-1 chat
session. join() here denotes creating a session for 1-to-1 access, so
a lot of this hinges upon the Object[] parameter in join()... this
doesn't feel quite right to me.
<br>
</blockquote>
<br>
As my example above shows, this isn't strictly necessary. There's no
reason to have the container create a new container for this simple
chat case. To implement a 'multiple chat groups with a lobby chat'
sort of approach it might be helpful to define new containers to
represent other chat groups, but it's not necessary for this simple
chat
<br>
<br>
<blockquote type="cite"><br>
To invite user2, user1 sends a message to user2 in the lobby container
via a ISharedObjectContext... not sure how to get one of these context
objects. I don't see a ISharedObject.getContext() method. </blockquote>
<br>
It's on the ISharedObjectConfig that is passed to the shared object via
the 'init' method. ISharedObjectConfig.getContext(). This is
explicitly modelled after the ServletConfig/ServletContext
relationship.
<br>
<br>
/And
<br>
<blockquote type="cite">ISharedContainerObject.getConfig() doesn't
return a ISharedObjectConfig which has the needed getContext() method.
<br>
</blockquote>
<br>
No, the ISharedObjectContainer.getConfig() is the config associated
with the container (not the config associated with the ISharedObject).
<br>
<br>
<blockquote type="cite"><br>
user2 would have to set up a listener in the lobby container for
invitation message types, and join the 1-to-1 chat session container by
calling join(). The ID of the chat session must be passed along in the
invitation message.
<br>
<br>
Does this sound right?
<br>
</blockquote>
<br>
Well yes, except that I would put most of what you are describing for
invitation messages and etc in the implementation of the Chat class.
The chat class I've provided simply sends around nickname/message
pairs...but an invitation message could easily also be
defined/responded to within the Chat class itself as you describe.
<br>
<br>
Hopefully this helps.
<br>
<br>
Scott
<br>
<br>
<blockquote type="cite"><br>
Li-Te
<br>
<br>
<br>
John F. Patterson wrote:
<br>
<br>
<blockquote type="cite">It would help me if we identified a few use
cases and worked them through using the API. The simplest is probably
starting a chat. We can worry later about actually using the chat.
For now, I just want to understand how it all gets started.
<br>
<br>
Normally, I think of chat as having three main steps to get it going:
<br>
<br>
1. One user initiates a chat session.
<br>
2. Somehow another user becomes informed of the existence of the chat
<br>
(the invite)
<br>
3. The second user joins the chat.
<br>
<br>
For step 1), I assume that I create a SharedContainer to correspond to
the chat session. Then I create a SharedObject that will be used to
accomplish the actual communication.
<br>
For step 2), I assume I must send the ID of the SharedContainer to the
other user. I don't believe the ECF provides an explicit way to do
this, but one could be invented on top of it.
<br>
For step 3), I assume the second user creates a SharedContainer of the
appropriate type (how do they know the type?) and Join the group
identified by the ID sent to them. Then somehow, they find the
SharedObject.
<br>
<br>
Do I have this right, as far as it goes? As you can see, I am a little
unclear on some of the specifics, particularly on how the SharedObjects
come to exist on the second machine. Are they brought into existence
upon joining the group? Does the second user learn about them via an
event?
<br>
<br>
I would find it helpful to see the code for this use case.
<br>
</blockquote>
</blockquote>
<br>
<pre wrap="">
<hr size="4" width="90%">
package org.eclipse.ecf.test.ui.actions;
import java.io.IOException;
import org.eclipse.ecf.core.ISharedObject;
import org.eclipse.ecf.core.ISharedObjectConfig;
import org.eclipse.ecf.core.ISharedObjectContext;
import org.eclipse.ecf.core.SharedObjectInitException;
import org.eclipse.ecf.core.events.RemoteSharedObjectEvent;
import org.eclipse.ecf.core.identity.ID;
import org.eclipse.ecf.core.util.Event;
public class Chat implements ISharedObject {
public Chat(String nickname) {
super();
}
String nickname;
ISharedObjectConfig config;
public void init(ISharedObjectConfig initData)
throws SharedObjectInitException {
this.config = initData;
}
public ID getID() {
if (config == null) return null;
else return config.getSharedObjectID();
}
public void handleEvent(Event event) {
// This is the code to handle a
if (event instanceof RemoteSharedObjectEvent) {
// We've got an instance of event sent by remote
// We'll assume it's a chat message
RemoteSharedObjectEvent chatEvent = (RemoteSharedObjectEvent) event;
handleChatEvent(chatEvent);
} else System.out.println("ID: "+getID().getName()+" got unknown event: "+event);
}
protected void handleChatEvent(RemoteSharedObjectEvent chatEvent) {
// It's actually an object array...see sendChatToRemote
Object [] data = (Object []) chatEvent.getData();
showChatToUI((String) data[0], (String) data[1]);
}
protected void showChatToUI(String senderNickname, String message) {
System.out.println("Received chat message from: "+senderNickname);
System.out.println("Message: "+message);
}
// This is method to call to send message to remotes
protected void sendChatToRemote(String message) {
ISharedObjectContext ctx = config.getContext();
Object [] data = new Object[] { nickname, message };
try {
// Note that null means to *all* remotes in current container
ctx.sendMessage(null,data);
} catch (IOException e) {
e.printStackTrace();
}
}
public void handleEvents(Event[] events) {
for(int i=0; i < events.length; i++) {
handleEvent(events[i]);
}
}
public void dispose(ID containerID) {
System.out.println("ID:"+getID().getName()+" dispose("+containerID.getName()+")");
config = null;
}
public Object getAdapter(Class clazz) {
System.out.println("ID:"+getID().getName()+" getAdapter("+clazz.getName()+")");
return null;
}
}
</pre>
</blockquote>
</body>
</html>
--------------000802090402060501040501--
|
|
|
| Re: How do SharedObjects become known on the remote systems [message #571102 is a reply to message #571068] |
Sun, 19 December 2004 18:49 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi John,
John F. Patterson wrote:
> In this analysis, I assume I send to Li-Te by performing a send on his
> chat object and he sends to me by performing a send on my chat object.
> Is this correct? Li-Te seemed to believe a connector would be needed,
> but that does not appear to be correct. Am I right on this?
A connector is not needed. Because (in this implementation) the Chat
instance ID (called 'chat' in this case) is named the same on all
participating processes (it's 'well-known'/assumed for this chat),
messages send by any Chat instance via:
config.getContext().sendMessage(null, <whatever>)
<whatever> will be directed automatically to all remote instances of the
Chat object with the name 'chat' (but not to other named shared objects).
Note the 'null' in the above sendMessage means 'send to all remotes with
ID 'chat' that exist within this container'. It is, of course, possible
that sendMessage would be used under other app circumstances (e.g. 1-1
conversation) as follows:
config.getContext().sendMessage(specificID, <whatever>)
>
> How does a remote system come to "know" about SharedObjects created by
> someone else? I assume the SharedObject is not automatically created.
In the implementation below, the shared object 'chat' is assumed to be
there (because of the assumed name 'chat').
In general, however, a shared object 'primary copy' needs to be able to
dynamically create/destroy/control remote replicas of itself.
That's the purpose of
config.getContext().sendCreate(...);
config.getContext().sendDispose(...);
> Do I learn of the ID in a listener on the Container?
You can...if it's not well known, yes. Actually, I suspect that these
sorts of notification (of ID arrival/departure) are going to be so
commonly needed that I've been assuming that most providers will want to
*by default* (without any explicit 'addlistener' additions by the shared
object) send some events via handleEvent(...) that notify of the
arrival/departure of sharedobjects and of group members. So in the
provider I'm implementing, for example, there will be events delivered
to the sharedobject (via handleEvents(...) that indicate that a new
sharedobject created/disposed and that a group member arrived/departed.
I'm not sure whether these notifications should be required of all
providers, however...it's probably something that should be left up to
the provider (whether such notifications should be automatically
delivered to a sharedobject, or whether explicit registration is
required to receive such events).
>Will I learn of
> the type as well, so that I will know what sort of object needs to be
> created?
The SharedObjectDescription passed into the sendCreate(...) call
contains all the information necessary to create a remote replica of the
given shared object (it's 'root' classname, it's id, homeid, any
constructor params, and it's properties).
Incidently...there is some trickiness associated with classloaders
necessary (caused by OSGI 'classloader-per-plugin' model in Eclipse 3.0)
to be able to have the provider code that receives a sendCreate message
be able to 'see' the class that it's trying to load...if it's in a
plugin other than the provider plugin. The class specified in the
SharedObjectDescription is a String, and so the provider classloader
needs to call:
Class.forName(description.getClassName())
(or classloader.loadClass(...))
to load the class before creating the instance.
Happily, the OSGI model allows for specifying 'dynamic-importpackages'
so that a given provider plugin can access packages/classes defined by
other plugins.
Thanks,
Scott
>
> jfp
>
> Scott Lewis wrote:
>
>> Hi Li-Te and all,
>>
>> Here are some comments on Li-Te's chat application.
>>
>> Li-Te wrote:
>>
>>> (note: newsgroup is acting funny .... seeing double posts. so
>>> apologies if this appears twice, or if someone already answered
>>> John's question)
>>>
>>> Here is my rough understanding of this from what I've read so far in
>>> the javadoc and online documentation. Someone say something in if
>>> I'm wrong here. Putting in "???" in unknown bits.
>>>
>>> --- for user 1
>>>
>>> // create a chat container - ignore what kind of protocols, etc for now
>>> ISharedObjectContainer chatLobby =
>>> SharedObjectContainerFactory.
>>> makeSharedObjectContainer("chatLobby");
>>
>>
>> Yes. This is the first step...to create a container for the chat.
>>
>> In preference to all of the code you have below, I would design things
>> so that the program would be structured as follows:
>>
>> // join the group...this connects to some server...using any/all
>> // authentication required by 'chatLobby'
>> chatLobby.joinGroup(IDFactory.makeStringID("slewis@server.com",null);
>>
>> // Create an ISharedObject that represents me...i.e. has my nickname
>> Chat chat = new Chat("slewis");
>>
>> // And add the shared object to the container...this will init the Chat
>> // instance and allow it to start sending/receiving messages
>> chatLobby.getSharedObjectManager().addSharedObject(IDFactory .makeStringID( "chat"),chat,new
>> Properties(),null);
>>
>> For a simple chat, this would be all I would need. All the
>> functionality of sending/receiving messages would be implemented in
>> the Chat class. I've attached a copy of the source to this class in
>> this email, and I'll also be checking it in to the
>> org.eclipse.ecf.test plugin later today.
>>
>> User two would have *exactly the same code* except for
>>
>> "slewis@server.com" would be changed to "li-te_cheng@us.ibm.com"
>> and new Chat("slewis") would be changed to "li-te". The Chat object
>> code itself would also be the same on both/all participants.
>>
>> There would be other ways to implement this functionality, but I think
>> this is the most straightforward. The basic notion is that the
>> ISharedObject is really responsible for implementing all of the 'chat'
>> functionality (or presence functionality, or file sharing
>> functionality, etc).
>>
>> Some more comments are interspersed below:
>>
>> <code deleted>
>>
>>> --- for user 2
>>>
>>> // similar process like user 1 (log into a chat lobby) and
>>> // then in the chatLobby listener defined by calling
>>> // chatLobby.addListener(), check if an invitation message
>>> // came through. the invite should hold chatSessionId so
>>> // user 2 can do something like this
>>>
>>> private void joinSession( ID chatSessionId )
>>> {
>>> ISharedObjectContainer chatSession =
>>> SharedObjectContainerFactory.
>>> makeSharedObjectContainer("chatSession");
>>>
>>> // e.g. join info could might be a password if the chat room is
>>> // protected
>>> Object joinInfo = ...; // ???
>>> chatSession.joinGroup(chatSessionId,joinInfo);
>>> }
>>>
>>>
>>> Several notes:
>>>
>>> In this setup, there is a container for a "lobby", the public space
>>> to discover other members. The lobby is where people can send
>>> invites, and find out who's online (e.g. buddy list). Shared objects
>>> in the lobby are really tokens for user presence : if user1's object
>>> is in the lobby, then user1 is "online". Login is done via the
>>> join() method. Listing who's online is done by listing what object
>>> IDs are in the "lobby" container (after join() is called).
>>
>>
>> Yes.
>>
>>>
>>> The lobby needs a unique ID for all users to connect to. This is
>>> done by defining an ID via namespaces. IDFactory.getNamespace(...)
>>> would define an appropriate namespace for IDFactory.makeID(...)
>>
>>
>> Yes.
>>
>>>
>>> To start a chat, user1 creates another container for the 1-to-1 chat
>>> session. join() here denotes creating a session for 1-to-1 access,
>>> so a lot of this hinges upon the Object[] parameter in join()... this
>>> doesn't feel quite right to me.
>>
>>
>> As my example above shows, this isn't strictly necessary. There's no
>> reason to have the container create a new container for this simple
>> chat case. To implement a 'multiple chat groups with a lobby chat'
>> sort of approach it might be helpful to define new containers to
>> represent other chat groups, but it's not necessary for this simple chat
>>
>>>
>>> To invite user2, user1 sends a message to user2 in the lobby
>>> container via a ISharedObjectContext... not sure how to get one of
>>> these context objects. I don't see a ISharedObject.getContext()
>>> method.
>>
>>
>> It's on the ISharedObjectConfig that is passed to the shared object
>> via the 'init' method. ISharedObjectConfig.getContext(). This is
>> explicitly modelled after the ServletConfig/ServletContext relationship.
>>
>> /And
>>
>>> ISharedContainerObject.getConfig() doesn't return a
>>> ISharedObjectConfig which has the needed getContext() method.
>>
>>
>> No, the ISharedObjectContainer.getConfig() is the config associated
>> with the container (not the config associated with the ISharedObject).
>>
>>>
>>> user2 would have to set up a listener in the lobby container for
>>> invitation message types, and join the 1-to-1 chat session container
>>> by calling join(). The ID of the chat session must be passed along
>>> in the invitation message.
>>>
>>> Does this sound right?
>>
>>
>> Well yes, except that I would put most of what you are describing for
>> invitation messages and etc in the implementation of the Chat class.
>> The chat class I've provided simply sends around nickname/message
>> pairs...but an invitation message could easily also be
>> defined/responded to within the Chat class itself as you describe.
>>
>> Hopefully this helps.
>>
>> Scott
>>
>>>
>>> Li-Te
>>>
>>>
>>> John F. Patterson wrote:
>>>
>>>> It would help me if we identified a few use cases and worked them
>>>> through using the API. The simplest is probably starting a chat.
>>>> We can worry later about actually using the chat. For now, I just
>>>> want to understand how it all gets started.
>>>>
>>>> Normally, I think of chat as having three main steps to get it going:
>>>>
>>>> 1. One user initiates a chat session.
>>>> 2. Somehow another user becomes informed of the existence of the chat
>>>> (the invite)
>>>> 3. The second user joins the chat.
>>>>
>>>> For step 1), I assume that I create a SharedContainer to correspond
>>>> to the chat session. Then I create a SharedObject that will be used
>>>> to accomplish the actual communication.
>>>> For step 2), I assume I must send the ID of the SharedContainer to
>>>> the other user. I don't believe the ECF provides an explicit way to
>>>> do this, but one could be invented on top of it.
>>>> For step 3), I assume the second user creates a SharedContainer of
>>>> the appropriate type (how do they know the type?) and Join the group
>>>> identified by the ID sent to them. Then somehow, they find the
>>>> SharedObject.
>>>>
>>>> Do I have this right, as far as it goes? As you can see, I am a
>>>> little unclear on some of the specifics, particularly on how the
>>>> SharedObjects come to exist on the second machine. Are they brought
>>>> into existence upon joining the group? Does the second user learn
>>>> about them via an event?
>>>>
>>>> I would find it helpful to see the code for this use case.
>>>
>>
>> ------------------------------------------------------------ ------------
>>
>>package org.eclipse.ecf.test.ui.actions;
>>
>>import java.io.IOException;
>>
>>import org.eclipse.ecf.core.ISharedObject;
>>import org.eclipse.ecf.core.ISharedObjectConfig;
>>import org.eclipse.ecf.core.ISharedObjectContext;
>>import org.eclipse.ecf.core.SharedObjectInitException;
>>import org.eclipse.ecf.core.events.RemoteSharedObjectEvent;
>>import org.eclipse.ecf.core.identity.ID;
>>import org.eclipse.ecf.core.util.Event;
>>
>>public class Chat implements ISharedObject {
>>
>> public Chat(String nickname) {
>> super();
>> }
>>
>> String nickname;
>> ISharedObjectConfig config;
>>
>> public void init(ISharedObjectConfig initData)
>> throws SharedObjectInitException {
>> this.config = initData;
>> }
>>
>> public ID getID() {
>> if (config == null) return null;
>> else return config.getSharedObjectID();
>> }
>>
>> public void handleEvent(Event event) {
>> // This is the code to handle a
>> if (event instanceof RemoteSharedObjectEvent) {
>> // We've got an instance of event sent by remote
>> // We'll assume it's a chat message
>> RemoteSharedObjectEvent chatEvent = (RemoteSharedObjectEvent) event;
>> handleChatEvent(chatEvent);
>> } else System.out.println("ID: "+getID().getName()+" got unknown event: "+event);
>> }
>>
>> protected void handleChatEvent(RemoteSharedObjectEvent chatEvent) {
>> // It's actually an object array...see sendChatToRemote
>> Object [] data = (Object []) chatEvent.getData();
>> showChatToUI((String) data[0], (String) data[1]);
>> }
>> protected void showChatToUI(String senderNickname, String message) {
>> System.out.println("Received chat message from: "+senderNickname);
>> System.out.println("Message: "+message);
>> }
>>
>> // This is method to call to send message to remotes
>> protected void sendChatToRemote(String message) {
>> ISharedObjectContext ctx = config.getContext();
>> Object [] data = new Object[] { nickname, message };
>> try {
>> // Note that null means to *all* remotes in current container
>> ctx.sendMessage(null,data);
>> } catch (IOException e) {
>> e.printStackTrace();
>> }
>> }
>> public void handleEvents(Event[] events) {
>> for(int i=0; i < events.length; i++) {
>> handleEvent(events[i]);
>> }
>> }
>>
>> public void dispose(ID containerID) {
>> System.out.println("ID:"+getID().getName()+" dispose("+containerID.getName()+")");
>> config = null;
>> }
>>
>> public Object getAdapter(Class clazz) {
>> System.out.println("ID:"+getID().getName()+" getAdapter("+clazz.getName()+")");
>> return null;
>> }
>>
>>}
>>
>>
|
|
|
| Ah... The objects have a common ID [message #573791 is a reply to message #571102] |
Mon, 20 December 2004 14:40 |
| Eclipse User |
|
|
|
Originally posted by: john_patterson.us.ibm.com
OK, I see where I messed up. I mistook the names passed in to the Chat
object as the idenitifiers, but they clearly are not the IDs. They are
merely nicknames that are bundled into the sent object (actually Object
array). The ID for the objects is "chat" on both sides. Presumably,
everyone with access to the container who also creates the "chat"
object. may use the sendObjectToRemote method and the chat will go to
System.out. Is this right?
jfp
Scott Lewis wrote:
> Hi John,
>
> John F. Patterson wrote:
>
>> In this analysis, I assume I send to Li-Te by performing a send on
>> his chat object and he sends to me by performing a send on my chat
>> object. Is this correct? Li-Te seemed to believe a connector would
>> be needed, but that does not appear to be correct. Am I right on this?
>
>
> A connector is not needed. Because (in this implementation) the Chat
> instance ID (called 'chat' in this case) is named the same on all
> participating processes (it's 'well-known'/assumed for this chat),
> messages send by any Chat instance via:
>
> config.getContext().sendMessage(null, <whatever>)
>
> <whatever> will be directed automatically to all remote instances of
> the Chat object with the name 'chat' (but not to other named shared
> objects).
>
> Note the 'null' in the above sendMessage means 'send to all remotes
> with ID 'chat' that exist within this container'. It is, of course,
> possible that sendMessage would be used under other app circumstances
> (e.g. 1-1 conversation) as follows:
>
> config.getContext().sendMessage(specificID, <whatever>)
>
>>
>> How does a remote system come to "know" about SharedObjects created
>> by someone else? I assume the SharedObject is not automatically
>> created.
>
>
> In the implementation below, the shared object 'chat' is assumed to be
> there (because of the assumed name 'chat').
>
> In general, however, a shared object 'primary copy' needs to be able
> to dynamically create/destroy/control remote replicas of itself.
>
> That's the purpose of
>
> config.getContext().sendCreate(...);
> config.getContext().sendDispose(...);
>
>> Do I learn of the ID in a listener on the Container?
>
>
> You can...if it's not well known, yes. Actually, I suspect that these
> sorts of notification (of ID arrival/departure) are going to be so
> commonly needed that I've been assuming that most providers will want
> to *by default* (without any explicit 'addlistener' additions by the
> shared object) send some events via handleEvent(...) that notify of
> the arrival/departure of sharedobjects and of group members. So in
> the provider I'm implementing, for example, there will be events
> delivered to the sharedobject (via handleEvents(...) that indicate
> that a new sharedobject created/disposed and that a group member
> arrived/departed. I'm not sure whether these notifications should be
> required of all providers, however...it's probably something that
> should be left up to the provider (whether such notifications should
> be automatically delivered to a sharedobject, or whether explicit
> registration is required to receive such events).
>
>> Will I learn of the type as well, so that I will know what sort of
>> object needs to be created?
>
>
> The SharedObjectDescription passed into the sendCreate(...) call
> contains all the information necessary to create a remote replica of
> the given shared object (it's 'root' classname, it's id, homeid, any
> constructor params, and it's properties).
>
> Incidently...there is some trickiness associated with classloaders
> necessary (caused by OSGI 'classloader-per-plugin' model in Eclipse
> 3.0) to be able to have the provider code that receives a sendCreate
> message be able to 'see' the class that it's trying to load...if it's
> in a plugin other than the provider plugin. The class specified in
> the SharedObjectDescription is a String, and so the provider
> classloader needs to call:
>
> Class.forName(description.getClassName())
> (or classloader.loadClass(...))
>
> to load the class before creating the instance.
>
> Happily, the OSGI model allows for specifying 'dynamic-importpackages'
> so that a given provider plugin can access packages/classes defined by
> other plugins.
>
> Thanks,
>
> Scott
>
>
>>
>> jfp
>>
>> Scott Lewis wrote:
>>
>>> Hi Li-Te and all,
>>>
>>> Here are some comments on Li-Te's chat application.
>>>
>>> Li-Te wrote:
>>>
>>>> (note: newsgroup is acting funny .... seeing double posts. so
>>>> apologies if this appears twice, or if someone already answered
>>>> John's question)
>>>>
>>>> Here is my rough understanding of this from what I've read so far
>>>> in the javadoc and online documentation. Someone say something in
>>>> if I'm wrong here. Putting in "???" in unknown bits.
>>>>
>>>> --- for user 1
>>>>
>>>> // create a chat container - ignore what kind of protocols, etc for
>>>> now
>>>> ISharedObjectContainer chatLobby =
>>>> SharedObjectContainerFactory.
>>>> makeSharedObjectContainer("chatLobby");
>>>
>>>
>>>
>>> Yes. This is the first step...to create a container for the chat.
>>>
>>> In preference to all of the code you have below, I would design
>>> things so that the program would be structured as follows:
>>>
>>> // join the group...this connects to some server...using any/all
>>> // authentication required by 'chatLobby'
>>> chatLobby.joinGroup(IDFactory.makeStringID("slewis@server.com",null);
>>>
>>> // Create an ISharedObject that represents me...i.e. has my nickname
>>> Chat chat = new Chat("slewis");
>>>
>>> // And add the shared object to the container...this will init the Chat
>>> // instance and allow it to start sending/receiving messages
>>> chatLobby.getSharedObjectManager().addSharedObject(IDFactory .makeStringID( "chat"),chat,new
>>> Properties(),null);
>>>
>>> For a simple chat, this would be all I would need. All the
>>> functionality of sending/receiving messages would be implemented in
>>> the Chat class. I've attached a copy of the source to this class in
>>> this email, and I'll also be checking it in to the
>>> org.eclipse.ecf.test plugin later today.
>>>
>>> User two would have *exactly the same code* except for
>>>
>>> "slewis@server.com" would be changed to "li-te_cheng@us.ibm.com"
>>> and new Chat("slewis") would be changed to "li-te". The Chat object
>>> code itself would also be the same on both/all participants.
>>>
>>> There would be other ways to implement this functionality, but I
>>> think this is the most straightforward. The basic notion is that
>>> the ISharedObject is really responsible for implementing all of the
>>> 'chat' functionality (or presence functionality, or file sharing
>>> functionality, etc).
>>>
>>> Some more comments are interspersed below:
>>>
>>> <code deleted>
>>>
>>>> --- for user 2
>>>>
>>>> // similar process like user 1 (log into a chat lobby) and
>>>> // then in the chatLobby listener defined by calling
>>>> // chatLobby.addListener(), check if an invitation message
>>>> // came through. the invite should hold chatSessionId so
>>>> // user 2 can do something like this
>>>>
>>>> private void joinSession( ID chatSessionId )
>>>> {
>>>> ISharedObjectContainer chatSession =
>>>> SharedObjectContainerFactory.
>>>> makeSharedObjectContainer("chatSession");
>>>>
>>>> // e.g. join info could might be a password if the chat room is
>>>> // protected
>>>> Object joinInfo = ...; // ???
>>>> chatSession.joinGroup(chatSessionId,joinInfo);
>>>> }
>>>>
>>>>
>>>> Several notes:
>>>>
>>>> In this setup, there is a container for a "lobby", the public space
>>>> to discover other members. The lobby is where people can send
>>>> invites, and find out who's online (e.g. buddy list). Shared
>>>> objects in the lobby are really tokens for user presence : if
>>>> user1's object is in the lobby, then user1 is "online". Login is
>>>> done via the join() method. Listing who's online is done by
>>>> listing what object IDs are in the "lobby" container (after join()
>>>> is called).
>>>
>>>
>>>
>>> Yes.
>>>
>>>>
>>>> The lobby needs a unique ID for all users to connect to. This is
>>>> done by defining an ID via namespaces. IDFactory.getNamespace(...)
>>>> would define an appropriate namespace for IDFactory.makeID(...)
>>>
>>>
>>>
>>> Yes.
>>>
>>>>
>>>> To start a chat, user1 creates another container for the 1-to-1
>>>> chat session. join() here denotes creating a session for 1-to-1
>>>> access, so a lot of this hinges upon the Object[] parameter in
>>>> join()... this doesn't feel quite right to me.
>>>
>>>
>>>
>>> As my example above shows, this isn't strictly necessary. There's
>>> no reason to have the container create a new container for this
>>> simple chat case. To implement a 'multiple chat groups with a lobby
>>> chat' sort of approach it might be helpful to define new containers
>>> to represent other chat groups, but it's not necessary for this
>>> simple chat
>>>
>>>>
>>>> To invite user2, user1 sends a message to user2 in the lobby
>>>> container via a ISharedObjectContext... not sure how to get one of
>>>> these context objects. I don't see a ISharedObject.getContext()
>>>> method.
>>>
>>>
>>>
>>> It's on the ISharedObjectConfig that is passed to the shared object
>>> via the 'init' method. ISharedObjectConfig.getContext(). This is
>>> explicitly modelled after the ServletConfig/ServletContext
>>> relationship.
>>>
>>> /And
>>>
>>>> ISharedContainerObject.getConfig() doesn't return a
>>>> ISharedObjectConfig which has the needed getContext() method.
>>>
>>>
>>>
>>> No, the ISharedObjectContainer.getConfig() is the config associated
>>> with the container (not the config associated with the ISharedObject).
>>>
>>>>
>>>> user2 would have to set up a listener in the lobby container for
>>>> invitation message types, and join the 1-to-1 chat session
>>>> container by calling join(). The ID of the chat session must be
>>>> passed along in the invitation message.
>>>>
>>>> Does this sound right?
>>>
>>>
>>>
>>> Well yes, except that I would put most of what you are describing
>>> for invitation messages and etc in the implementation of the Chat
>>> class. The chat class I've provided simply sends around
>>> nickname/message pairs...but an invitation message could easily also
>>> be defined/responded to within the Chat class itself as you describe.
>>>
>>> Hopefully this helps.
>>>
>>> Scott
>>>
>>>>
>>>> Li-Te
>>>>
>>>>
>>>> John F. Patterson wrote:
>>>>
>>>>> It would help me if we identified a few use cases and worked them
>>>>> through using the API. The simplest is probably starting a chat.
>>>>> We can worry later about actually using the chat. For now, I just
>>>>> want to understand how it all gets started.
>>>>>
>>>>> Normally, I think of chat as having three main steps to get it going:
>>>>>
>>>>> 1. One user initiates a chat session.
>>>>> 2. Somehow another user becomes informed of the existence of the
>>>>> chat
>>>>> (the invite)
>>>>> 3. The second user joins the chat.
>>>>>
>>>>> For step 1), I assume that I create a SharedContainer to
>>>>> correspond to the chat session. Then I create a SharedObject that
>>>>> will be used to accomplish the actual communication.
>>>>> For step 2), I assume I must send the ID of the SharedContainer to
>>>>> the other user. I don't believe the ECF provides an explicit way
>>>>> to do this, but one could be invented on top of it.
>>>>> For step 3), I assume the second user creates a SharedContainer of
>>>>> the appropriate type (how do they know the type?) and Join the
>>>>> group identified by the ID sent to them. Then somehow, they find
>>>>> the SharedObject.
>>>>>
>>>>> Do I have this right, as far as it goes? As you can see, I am a
>>>>> little unclear on some of the specifics, particularly on how the
>>>>> SharedObjects come to exist on the second machine. Are they
>>>>> brought into existence upon joining the group? Does the second
>>>>> user learn about them via an event?
>>>>>
>>>>> I would find it helpful to see the code for this use case.
>>>>
>>>>
>>>
>>> ------------------------------------------------------------ ------------
>>>
>>>
>>> package org.eclipse.ecf.test.ui.actions;
>>>
>>> import java.io.IOException;
>>>
>>> import org.eclipse.ecf.core.ISharedObject;
>>> import org.eclipse.ecf.core.ISharedObjectConfig;
>>> import org.eclipse.ecf.core.ISharedObjectContext;
>>> import org.eclipse.ecf.core.SharedObjectInitException;
>>> import org.eclipse.ecf.core.events.RemoteSharedObjectEvent;
>>> import org.eclipse.ecf.core.identity.ID;
>>> import org.eclipse.ecf.core.util.Event;
>>>
>>> public class Chat implements ISharedObject {
>>>
>>> public Chat(String nickname) {
>>> super();
>>> }
>>>
>>> String nickname;
>>> ISharedObjectConfig config;
>>> public void init(ISharedObjectConfig initData)
>>> throws SharedObjectInitException {
>>> this.config = initData;
>>> }
>>>
>>> public ID getID() {
>>> if (config == null) return null;
>>> else return config.getSharedObjectID();
>>> }
>>> public void handleEvent(Event event) {
>>> // This is the code to handle a
>>> if (event instanceof RemoteSharedObjectEvent) {
>>> // We've got an instance of event sent by remote
>>> // We'll assume it's a chat message
>>> RemoteSharedObjectEvent chatEvent =
>>> (RemoteSharedObjectEvent) event;
>>> handleChatEvent(chatEvent);
>>> } else System.out.println("ID: "+getID().getName()+" got
>>> unknown event: "+event);
>>> }
>>> protected void handleChatEvent(RemoteSharedObjectEvent
>>> chatEvent) {
>>> // It's actually an object array...see sendChatToRemote
>>> Object [] data = (Object []) chatEvent.getData();
>>> showChatToUI((String) data[0], (String) data[1]);
>>> }
>>> protected void showChatToUI(String senderNickname, String message) {
>>> System.out.println("Received chat message from:
>>> "+senderNickname);
>>> System.out.println("Message: "+message);
>>> }
>>>
>>> // This is method to call to send message to remotes
>>> protected void sendChatToRemote(String message) {
>>> ISharedObjectContext ctx = config.getContext();
>>> Object [] data = new Object[] { nickname, message };
>>> try {
>>> // Note that null means to *all* remotes in current
>>> container
>>> ctx.sendMessage(null,data);
>>> } catch (IOException e) {
>>> e.printStackTrace();
>>> }
>>> }
>>> public void handleEvents(Event[] events) {
>>> for(int i=0; i < events.length; i++) {
>>> handleEvent(events[i]);
>>> }
>>> }
>>>
>>> public void dispose(ID containerID) {
>>> System.out.println("ID:"+getID().getName()+"
>>> dispose("+containerID.getName()+")");
>>> config = null;
>>> }
>>>
>>> public Object getAdapter(Class clazz) {
>>> System.out.println("ID:"+getID().getName()+"
>>> getAdapter("+clazz.getName()+")");
>>> return null;
>>> }
>>>
>>> }
>>>
>>>
|
|
| |
| Concerns about this simple chat [message #573837 is a reply to message #573806] |
Thu, 23 December 2004 01:42 |
| Eclipse User |
|
|
|
Originally posted by: john_patterson.us.ibm.com
I understand that the simple chat outlined here is really more or less a
hello world example, but I would like to explore my understanding by
rasing some concerns about it.
First, since the ID of the SharedObject is based on a well-known name,
i.e., "chat" anyone who has permission to join the server.com container
may join the chat. How do we restrict the chat to a limited audience?
One approach seems to be to create the chat object with a random name
and do a sendCreate to those we wish to invite. Does this sound right?
Is there some way to prevent those I invite from expanding the
membership by doing a sendCreate to others?
Second, there does not appear to be any way to know who has joined the
chat. Thus, anyone could lurk and others would be unaware of the
presence. Shouldn't it be possible to learn who has created the chat
object, e.g., something analogous to the members list for the container?
Third, since the name associated with a chat entry is completely under
the control of the user, anyone could contribute to the chat without
ever revealing the login name associated with their access to
server.com. Do the messages arrive tagged by the authenticated name of
the sender? If so, why wouldn't we use that name in the chat transcript?
jfp
Scott Lewis wrote:
> Hi John,
>
> John F. Patterson wrote:
>
>> OK, I see where I messed up. I mistook the names passed in to the
>> Chat object as the idenitifiers, but they clearly are not the IDs.
>> They are merely nicknames that are bundled into the sent object
>> (actually Object array). The ID for the objects is "chat" on both
>> sides. Presumably, everyone with access to the container who also
>> creates the "chat" object. may use the sendObjectToRemote method and
>> the chat will go to System.out. Is this right?
>
>
> Yes indeed!
>
> Scott
|
|
|
| Let me try again [message #573873 is a reply to message #571009] |
Thu, 23 December 2004 01:54 |
| Eclipse User |
|
|
|
Originally posted by: john_patterson.us.ibm.com
What confuses me is that the two users use different Group IDs, i.e.,
slewis@server.com and li-te@server.com. It is as if you are bundling
the container name "server.com" and the member name into the GroupID.
Is this correct? If we later ask for the Group member IDs, what do we
get? "slewis" and "li-te" or the two full names? If we ask for the
container ID, do we get "server.com"?
jfp
Scott Lewis wrote:
> Hi John,
>
> John F. Patterson wrote:
>
>> Scott:
>>
>> This still surprises me, but it is clarifying. You seem to equate
>> the container with the server, or the rendezvous point, rather than
>> with a meeting, or mutlipoint communication context.
>> Is that correct?
>
>
> The notion is that the container represents access to a distributed
> group. This can be server-provided or not...and for conferencing or
> not...it's just defined as a group of processes that are communicating
> with one another for some reason (app) or another.
>
>>
>> Li-Te's original answer to my question was more like what I expected
>> because I was treating a chat as an instance of an eMeeting rather
>> than an IM.
>
>
> The Chat object I provided delivers an N-way chat...assuming that
> 'server.com' and the associated provider deliver that functionality.
>
>> You are right that there is a simpler form for simple 2-person chats.
>
>
> Like I said, the Chat object is not just a simple two-person
> chat...except in the case where the underlying provider only supports
> a 1-1 situation (e.g. some IM protocols).
>
>> Your answer still begs the question, however. Suppose we wanted a
>> multi-way chat or a chatRoom, how would we do it in ECF?
>
>
> As per the Chat object.
>
> >I usually
>
>> expect the server to act as a rendezvous point off of which we might
>> have several meetings.
>
>
> Sure...that's the role played by 'server.com' in the example.
>
>> Are these meetings containers also, or are they a special form of
>> SharedObject.
>
>
> The containers define the connectivity between processes. Some
> containers can only support communication via 1-1 chats. Other (most)
> providers are going to support a full n-way group. The shared objects
> define the communications functionality between the processes.
>
> There can be more than one object per container (i.e. different apps
> running on same comm system), and more than one comm system for a
> given app (i.e. using jabber and yahoo and SIP for a single application).
>
> Scott
>
>
>>
>> jfp
>>
>> Scott Lewis wrote:
>>
>>> Hi John,
>>>
>>> John F. Patterson wrote:
>>>
>>>> I'm confused. You indicate below that one person uses
>>>> "slewis@server.com" for the GroupID and the other uses
>>>> "li-te_cheng@us.ibm.com" for the GroupID. If they don't use the
>>>> same GroupID, how do they ever get their local proxies ties together.
>>>>
>>>> What am I missing?
>>>
>>>
>>>
>>>
>>> My mistake. What I meant was that the two addresses would have to
>>> be something like:
>>>
>>> "slewis@server.com"
>>>
>>> and "li-te_cheng@server.com"
>>>
>>> assuming that "server.com" was the host of the group (on a known port).
>>>
>>> If, for a given provider, other info was necessary, things might
>>> look like this:
>>>
>>> https://server.com:4444/mygroup
>>> or sip://<whatever sip further requires to identify a session>
>>> or jabber:slewis@jabber.com/group1
>>>
>>> In general, the syntax of the ID for joinging a group is going to be
>>> specific to the provider type. Depending upon the provider
>>> implementation, it may even be a provider-specific ID type (i.e.
>>> define a new ID type just for the given provider.
>>>
>>> Thanks for pointing out this error.
>>>
>>> Scott
>>>
>> [stuff deleted]
>
|
|
|
| Re: Let me try again [message #573919 is a reply to message #573873] |
Thu, 23 December 2004 05:18 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi John,
John F. Patterson wrote:
> What confuses me is that the two users use different Group IDs, i.e.,
> slewis@server.com and li-te@server.com. It is as if you are bundling
> the container name "server.com" and the member name into the GroupID.
I was simply using a short cut. The 'group name' really is just
'server.com'. I should have been the group id just be 'server.com'.
> Is this correct? If we later ask for the Group member IDs, what do we
> get? "slewis" and "li-te" or the two full names? If we ask for the
> container ID, do we get "server.com"?
Yes.
Scott
>
> jfp
>
> Scott Lewis wrote:
>
>> Hi John,
>>
>> John F. Patterson wrote:
>>
>>> Scott:
>>>
>>> This still surprises me, but it is clarifying. You seem to equate
>>> the container with the server, or the rendezvous point, rather than
>>> with a meeting, or mutlipoint communication context.
>>> Is that correct?
>>
>>
>>
>> The notion is that the container represents access to a distributed
>> group. This can be server-provided or not...and for conferencing or
>> not...it's just defined as a group of processes that are communicating
>> with one another for some reason (app) or another.
>>
>>>
>>> Li-Te's original answer to my question was more like what I expected
>>> because I was treating a chat as an instance of an eMeeting rather
>>> than an IM.
>>
>>
>>
>> The Chat object I provided delivers an N-way chat...assuming that
>> 'server.com' and the associated provider deliver that functionality.
>>
>>> You are right that there is a simpler form for simple 2-person chats.
>>
>>
>>
>> Like I said, the Chat object is not just a simple two-person
>> chat...except in the case where the underlying provider only supports
>> a 1-1 situation (e.g. some IM protocols).
>>
>>> Your answer still begs the question, however. Suppose we wanted a
>>> multi-way chat or a chatRoom, how would we do it in ECF?
>>
>>
>>
>> As per the Chat object.
>>
>> >I usually
>>
>>> expect the server to act as a rendezvous point off of which we might
>>> have several meetings.
>>
>>
>>
>> Sure...that's the role played by 'server.com' in the example.
>>
>>> Are these meetings containers also, or are they a special form of
>>> SharedObject.
>>
>>
>>
>> The containers define the connectivity between processes. Some
>> containers can only support communication via 1-1 chats. Other (most)
>> providers are going to support a full n-way group. The shared objects
>> define the communications functionality between the processes.
>>
>> There can be more than one object per container (i.e. different apps
>> running on same comm system), and more than one comm system for a
>> given app (i.e. using jabber and yahoo and SIP for a single application).
>>
>> Scott
>>
>>
>>>
>>> jfp
>>>
>>> Scott Lewis wrote:
>>>
>>>> Hi John,
>>>>
>>>> John F. Patterson wrote:
>>>>
>>>>> I'm confused. You indicate below that one person uses
>>>>> "slewis@server.com" for the GroupID and the other uses
>>>>> "li-te_cheng@us.ibm.com" for the GroupID. If they don't use the
>>>>> same GroupID, how do they ever get their local proxies ties together.
>>>>>
>>>>> What am I missing?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> My mistake. What I meant was that the two addresses would have to
>>>> be something like:
>>>>
>>>> "slewis@server.com"
>>>>
>>>> and "li-te_cheng@server.com"
>>>>
>>>> assuming that "server.com" was the host of the group (on a known port).
>>>>
>>>> If, for a given provider, other info was necessary, things might
>>>> look like this:
>>>>
>>>> https://server.com:4444/mygroup
>>>> or sip://<whatever sip further requires to identify a session>
>>>> or jabber:slewis@jabber.com/group1
>>>>
>>>> In general, the syntax of the ID for joinging a group is going to be
>>>> specific to the provider type. Depending upon the provider
>>>> implementation, it may even be a provider-specific ID type (i.e.
>>>> define a new ID type just for the given provider.
>>>>
>>>> Thanks for pointing out this error.
>>>>
>>>> Scott
>>>>
>>> [stuff deleted]
>>
>>
|
|
|
| Re: Concerns about this simple chat [message #573944 is a reply to message #573837] |
Thu, 23 December 2004 06:19 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi John,
John F. Patterson wrote:
> I understand that the simple chat outlined here is really more or less a
> hello world example, but I would like to explore my understanding by
> rasing some concerns about it.
>
> First, since the ID of the SharedObject is based on a well-known name,
> i.e., "chat" anyone who has permission to join the server.com container
> may join the chat. How do we restrict the chat to a limited audience?
In general, there will be many ways that containers could authenticate.
The purpose of the 2nd param in the joinGroup(ID,Object) method call
is to allow the passing of arbitary information for authentication (so,
for example, the Object could be a JAAS LoginContext).
> One approach seems to be to create the chat object with a random name
> and do a sendCreate to those we wish to invite. Does this sound
>right?
Even if the random name is truly unguessable, sending a message to an
invitee in the clear would be insecure.
The intention of the 'sendCreate' message is really to allow the
creation of a remote replica of a given shared object. This message
could be used to just communicate an ID for a new group, but it would
really just be preferable to use sendMessage(remoteInvitee,newGroupID).
Then the receiver could respond to this message by creating a new
container and joining that container. If the container requires
authentication and the invitee has it it can provide it, if it doesn't
have it then the invite was not appropriate anyway.
<stuff deleted>
>
> Second, there does not appear to be any way to know who has joined the
> chat.
No. config.getContext().getGroupMemberIDs() provides the current group
membership. Also:
config.getContext().getSharedObjectManager().getSharedObject IDs()
provides information about the current shared objects.
<stuff deleted>
>
> Third, since the name associated with a chat entry is completely under
> the control of the user, anyone could contribute to the chat without
> ever revealing the login name associated with their access to
> server.com.
This is just the way I chose to implement the nickname functionality in
this example. It would probably be more common for each user to have
their own 'presence' object...where the ID for the object really is a
full user identity. In that case, however, the chat would receive
messages from the presence object and use the sender object ID to be
sure that it's who it says it is.
Do the messages arrive tagged by the authenticated name of
> the sender?
Yes. In the events that are ISharedObjectEvent implementers have a
method ISharedObjectEvent.getSenderSharedObjectID(). Both messages from
remote replicas (ISharedObjectMessageEvent), and from local 'other'
shared objects (ISharedObjectEvent) have access to the 'sender'
>If so, why wouldn't we use that name in the chat transcript?
You could. And for some chats you surely would. Other chats it would
not be desired or necessary...it would depend upon the requirements on
the chat.
Scott
>
> jfp
> Scott Lewis wrote:
>
>> Hi John,
>>
>> John F. Patterson wrote:
>>
>>> OK, I see where I messed up. I mistook the names passed in to the
>>> Chat object as the idenitifiers, but they clearly are not the IDs.
>>> They are merely nicknames that are bundled into the sent object
>>> (actually Object array). The ID for the objects is "chat" on both
>>> sides. Presumably, everyone with access to the container who also
>>> creates the "chat" object. may use the sendObjectToRemote method and
>>> the chat will go to System.out. Is this right?
>>
>>
>>
>> Yes indeed!
>>
>> Scott
|
|
|
| Re: Concerns about this simple chat [message #573974 is a reply to message #573944] |
Fri, 24 December 2004 15:28 |
| Eclipse User |
|
|
|
Originally posted by: john_patterson.us.ibm.com
Comments embedded.
Scott Lewis wrote:
> Hi John,
>
> John F. Patterson wrote:
>
>> I understand that the simple chat outlined here is really more or
>> less a hello world example, but I would like to explore my
>> understanding by rasing some concerns about it.
>>
>> First, since the ID of the SharedObject is based on a well-known
>> name, i.e., "chat" anyone who has permission to join the server.com
>> container may join the chat. How do we restrict the chat to a
>> limited audience?
>
>
> In general, there will be many ways that containers could
> authenticate. The purpose of the 2nd param in the
> joinGroup(ID,Object) method call is to allow the passing of arbitary
> information for authentication (so, for example, the Object could be a
> JAAS LoginContext).
>
I guess I was asking whether I can restrict access to a SharedObject.
> > One approach seems to be to create the chat object with a random name
> > and do a sendCreate to those we wish to invite. Does this sound
> >right?
>
> Even if the random name is truly unguessable, sending a message to an
> invitee in the clear would be insecure.
> The intention of the 'sendCreate' message is really to allow the
> creation of a remote replica of a given shared object.
This is what I was trying to do. I was adopting the approach that the
container is like a large lobby to which many may come and that a chat
SharedObject will be created for a conversation within the lobby.
> This message could be used to just communicate an ID for a new group,
> but it would really just be preferable to use
> sendMessage(remoteInvitee,newGroupID). Then the receiver could
> respond to this message by creating a new container and joining that
> container. If the container requires authentication and the invitee
> has it it can provide it, if it doesn't have it then the invite was
> not appropriate anyway.
This seems to be an approach that is more like what Li-Te was outlining
at the outset. There are multiple ways to achieve a chat and it might
help the conversation to keep the approaches straight. I'll try to
outline the alternatives (as I see it) in a separate message.
>
> <stuff deleted>
>
>>
>> Second, there does not appear to be any way to know who has joined
>> the chat.
>
>
> No. config.getContext().getGroupMemberIDs() provides the current
> group membership. Also:
>
> config.getContext().getSharedObjectManager().getSharedObject IDs()
Does this tell me the set of shared objects that I have created? Or,
the set of all SharedObject IDs known to the container whether I am
participating in that SharedObject or not? If it is the latter, then my
notion of creating chat objects using random IDs might not work very
well for privacy, since anyone could get this list and start fishing for
chat SharedObjects that they were not invited to.
Also, if it is the full list, how do I know the type of the
SharedObject, i.e., the SharedObjectDescription?
>
> provides information about the current shared objects.
>
This tells you about the set of shared objects, but it does not tell you
who has actually created the shared object and is therefore
participating in it. Under many uses the SharedObject is like a
mini-meeting within the meeting. Often, we will want to know who is
participating in that SharedObject.
> <stuff deleted>
>
>>
>> Third, since the name associated with a chat entry is completely
>> under the control of the user, anyone could contribute to the chat
>> without ever revealing the login name associated with their access to
>> server.com.
>
>
> This is just the way I chose to implement the nickname functionality
> in this example. It would probably be more common for each user to
> have their own 'presence' object...where the ID for the object really
> is a full user identity. In that case, however, the chat would
> receive messages from the presence object and use the sender object ID
> to be
> sure that it's who it says it is.
>
If the 'presence' objects are still constructed by the user, isn't it
still an opportunity for spoofing. It seems to me that the provider is
the honest broker here. It needs to provide a way to associate the user
information (presence object) with the authenticated ID in such a way
that it cannot be spoofed. I do not currently see a way to do that in ECF.
> Do the messages arrive tagged by the authenticated name of
>
>> the sender?
>
>
> Yes. In the events that are ISharedObjectEvent implementers have a
> method ISharedObjectEvent.getSenderSharedObjectID(). Both messages
> from remote replicas (ISharedObjectMessageEvent), and from local
> 'other' shared objects (ISharedObjectEvent) have access to the 'sender'
>
Is this the ID of the group member or the ID of an object created by the
user for the purpose of exposing identity? The name
getSenderSharedObjectID suggests it is the latter. If the user creates
the presence object, then what prevents spoofing?
>> If so, why wouldn't we use that name in the chat transcript?
>
>
> You could. And for some chats you surely would. Other chats it would
> not be desired or necessary...it would depend upon the requirements on
> the chat.
>
Understood.
[stuff deleted]
|
|
|
| Four types of chat use cases [message #573999 is a reply to message #570605] |
Fri, 24 December 2004 16:02 |
| Eclipse User |
|
|
|
Originally posted by: john_patterson.us.ibm.com
This is a multi-part message in MIME format.
--------------070801030305030909070000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Based on the conversation so far, I am inclined to think that we have at
least four distinct types of chat use cases depending on whether
GroupIDs and chat SharedObject IDs are well-known or not. I have giiven
each of the types a name suggested by the manner in which it would be
used. This name is not really the important thing. What's important is
the combination of well-known and individualized IDs.
_ChatRoom -- GroupID well-known, Chat SharedObject ID well-known_
This is the simple approach that Scott outlined in response to Li-Te's
appraoch.
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.
_IM -- GroupID well-known, Chat SharedObject ID individualized_
I'm not sure this is the best way to do IM, but it feels kind of like
IM. 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, I decide I 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, I create a
ChatSharedObject, but give it a unique ID. Then, I 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.
_Chat Meeting -- GroupID individualized, Chat SharedObject ID well-known_
I think this is the approach that Li-Te was trying to outline. It
requires two containers: one for the actual chat and one to communicate
the individualized GroupID of that chat.
1. We all join a well-known container that Li-Te called 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.
_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.
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.
_
_
--------------070801030305030909070000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Based on the conversation so far, I am inclined to think that we have
at least four distinct types of chat use cases depending on whether
GroupIDs and chat SharedObject IDs are well-known or not. I have
giiven each of the types a name suggested by the manner in which it
would be used. This name is not really the important thing. What's
important is the combination of well-known and individualized IDs.<br>
<br>
<u>ChatRoom -- GroupID well-known, Chat SharedObject ID well-known</u><br>
This is the simple approach that Scott outlined in response to Li-Te's
appraoch.<br>
<br>
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.<br>
<br>
<u>IM -- GroupID well-known, Chat SharedObject ID individualized</u><br>
I'm not sure this is the best way to do IM, but it feels kind of like
IM. 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, I decide I 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, I create a
ChatSharedObject, but give it a unique ID. Then, I 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.<br>
<br>
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.<br>
<br>
<u>Chat Meeting -- GroupID individualized, Chat SharedObject ID
well-known</u><br>
I think this is the approach that Li-Te was trying to outline. It
requires two containers: one for the actual chat and one to communicate
the individualized GroupID of that chat.<br>
<br>
<ol>
<li>We all join a well-known container that Li-Te called 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. <br>
</li>
<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>
<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>
<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.<br>
</li>
</ol>
<br>
<u>Whisper -- GroupID individualized, Chat SharedObject ID
individualized<br>
</u>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.<br>
<br>
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.<br>
<br>
<u><br>
</u>
</body>
</html>
--------------070801030305030909070000--
|
|
|
| |
  |
Goto Forum:
Current Time: Thu Apr 18 04:21:21 GMT 2024
Powered by FUDForum. Page generated in 0.03721 seconds |
] 
Search
Help
Register
Login
Home
