[news.eclipse.technology.ecf] You seem to equate the container with the

["John F. Patterson" <john_patterson@xxxxxxxxxx>]

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@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
[stuff deleted]