| [news.eclipse.technology.ecf] Re: Let me try again |
Hi John,
What confuses me is that the two users use different Group IDs, i.e., slewis@xxxxxxxxxx and li-te@xxxxxxxxxxx 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"?
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:
[stuff deleted]Hi John,
John F. Patterson wrote:
I'm confused. You indicate below that one person uses "slewis@xxxxxxxxxx" for the GroupID and the other uses "li-te_cheng@xxxxxxxxxx" 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@xxxxxxxxxx"
and "li-te_cheng@xxxxxxxxxx"
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@xxxxxxxxxx/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