[Standards-JIG] NEW: Message Archiving

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Jun 9 09:37:50 UTC 2004

On Wednesday 09 June 2004 1:31 am, Jacek Konieczny wrote:
> On Tue, Jun 08, 2004 at 02:21:49PM -0700, Justin Karneges wrote:
> > On Tuesday 08 June 2004 3:06 am, Jacek Konieczny wrote:
> > > The <thread> values would be different only if one of clients used is
> > > broken or the "moving" participant always initiates each chat part.
> > > This is not true in most of my "moving" chats.
> >
> > If the "non-moving" participant initiates the chat, he would have to
> > begin a new chat with a new resource, and you'd have a new thread.
> When he initiates a new chat it is a new chat and a new thread. But if
> it just responds to what I have written in the previous active client it
> is just a continuation of the same chat. That is why I wrote "chat
> part".

Sorry, I'm very confused by your statements.  First you say that "the <thread> 
values would be different only if [...] the 'moving' participant always 
initiates each chat part."  Then I say that even if the 'non-moving' 
participant initiates a chat, there would still be a new thread.  And then 
you claim to agree with me.  Is there an argument remaining, or are we done 
here? :)

> > Should we differentiate a collection of "normal" messages vs a collection
> > of "chat" messages?  I suppose we could, but I was thinking 'chat' could
> > mean any kind of two-party discussion.  In that case, the types wouldn't
> > exactly match that of xmpp.
> Use of the same message types as in XMPP makes protocol simpler and more
> intuitive. That is always good.

When it makes sense to use them, then yes.  However, this may not be such a 
case.  If the collection is of type "chat", does this mean that all content 
of the collection is assumed to be message of type=chat?

I'll throw a wrench into this mess by suggesting that we might want to be able 
to log non-message items in a collection, such as presence changes.


More information about the Standards mailing list