Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)

From: "Boyer, David G (Dave)" <[email-masked]>
Date: Wed, 13 Mar 2002 10:58:37 -0500

We consistently use group "persistent" chat where I work.
When a user arrives after a discussion has begun he/she
can see what has been said.  If you use the one-shoot
pager model this will not be possible.  
This is useful for many reasons - a CRM example is a 
supervisor might need to join in a chat that has been
going on between an agent and a customer.  He/she will
need to see what has been said.

Dave Boyer

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Friday, March 08, 2002 12:57 PM
> To: Petri K. Koskelainen; Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt
> (threading)
> 
> 
> Group chat is of course a better fit for the
> session model. One-time delivery of messages to
> a group is a better fit for paging as Petri points
> out. How common is this? I can think of a TON of
> applications that fit this scenario. What features
> of group messaging can't be implemented in a paging
> mode?
> 
> /sean
> 
> --- "Petri K. Koskelainen" <[email-masked]>
> wrote:
> > 
> > > A discussion we REALLY need to have, is whether we
> > think that the paging
> > > model even makes sense for multiparty. I am really
> > not convinced. It
> > > seems that multiparty paging model is really more
> > like email, and that
> > > is not what IM is supposed to be. If group IM is
> > supposed to be real
> > > time, It just works so much better in the session
> > model. So many
> > > problems (like this one above) just evaporate.
> > > 
> > > Can anyone suggest a reason why the paging model
> > is preferrable for
> > > group chat? Simplicity is one, but that simplicity
> > might be elusive as
> > > you try to fill in all the missing pieces.
> > 
> > There are one-shot scenarios which require realtime
> > delivery
> > to a group. It is quite heavy operation to set up a
> > session,
> > send one IM, and then close the session. 
> > Example usage might be an urgent realtime
> > announcement to a 
> > pre-defined group.
> > 
> >  
> > BR,
> > --
> > Petri
> > 
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 
> =====
> Sean Olson <[email-masked]>
> 
> __________________________________________________
> Do You Yahoo!?
> Try FREE Yahoo! Mail - the world's greatest free email!
> http://mail.yahoo.com/
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 13 Mar 2002 11:07:25 -0600

> need to see what has been said.

That seems to me to be a function of the application server hosting the chat
and independent of the message transport used, although it does raise
interesting questions for both transport models we've commonly discussed.

--
Dean

---

From: Sean Olson <[email-masked]>
Date: Wed, 13 Mar 2002 09:34:06 -0800 (PST)

There is no reason this cannot be achieved with the
paging model. In fact neither model directly provides 
support for what you are talking about -- and neither
prevents building what you want. I can see the 
usefulness of this feature, but I expect you will
need/want a separate channel to look at the history
of a chat "session". If nothing else, you would
want to be able to separate past messages from
live chat without mistakenly discarding a "past" 
message as being out of context.

/sean

=====