[JDEV] id attr in message packets

[Constantin Nickonov]

You could also make the 'thread' attribute hold more than one value (choose
your delimeter), i.e.,

  <thread>root;parent;grandparent;etc</thread>

Since your client need only communicate with others like it, you can both
generate and make sense of this value at any point.

> -----Original Message-----
> From: Sean Wheeler [mailto:swheeler at media.mit.edu]
> Sent: Monday, July 15, 2002 8:58 PM
> To: jdev at jabber.org
> Subject: Re: [JDEV] id attr in message packets
> 
> 
> 
> Thanks for the explanation. Your point about message ordering is well
> taken, I imagine many would complain if servers did not ensure ordered
> arrival.  I now understand the id tag is not really for pinning down
> messages in the conversation but more as a client 
> convenience. This sucks,
> so since I'm not building an IM client and I don't have to 
> interact with
> any other clients in my project I might have to veer from the 
> standard for
> my purposes.
> 
> I think my problem does exist and in fact is a general one if you
> want/need to think of an interchange as a nested tree 
> structure. A reply
> is a child node, and your point is well taken that preserving 
> ordering of
> messages from a single client helps a lot. But since the tree 
> is deeply
> nested, how can you make reference to any node in the tree?  My first
> interpretation of what a thread "should be" is a reference to the root
> node.  This is actually the case, but in a more limited way, since the
> protocol only creates a tree of depth 1.
> 
> One scheme allowing 'n-depth tree' conversations is for a 
> child to be able
> to identify its parent, and this is what I was looking at the 
> id tag for.
> Another more elegant scheme is to use a tag that refers to 
> the root node
> of the implicit tree structure, call it 'root', or 'conversation' or
> whatever, and stick it in an x tag in another namespace.  Given the
> protocol and the common usage of id, this creates the kind of tree I'm
> looking for, but there's no assurance that the tree structure is
> accurately represented if a third party that doesnt have the full
> conversation history is thrown in.  For this the implicit root of the
> conversation would have to identify itself somehow, either by adding
> another tag in the x namespace, setting thread and root to 
> the same value,
> etc...
> 
> I'll have to take a closer look at JEP-0033.
> 
> Sean
> 
> 
> On Mon, 15 Jul 2002, Ben Schumacher wrote:
> 
> > On Sun, 14 Jul 2002, Sean Wheeler wrote:
> > > On Sun, 14 Jul 2002, Jeremy Nickurak wrote:
> > > >
> > > > The id attribute is intended to be used so that the 
> sender and receiver
> > > > can refer to particular messages. For example, someone 
> might implement a
> > > > "addendum" message type/namespace that changes some 
> element of the
> > > > previous message:
> > > >
> > > > <message id="3" type="addendum" from="bar at media" to="foo at media">
> > > >    <x xmlns="jabber:x:addendum">
> > > >       <append id="1">
> > > >          See also http://somepage.com/ for more details.
> > > >       </append>
> > > >    </x>
> > > > </message>
> > > >
> > > > That way, the <append> tag's "id" attribute can be 
> uniquesly associated
> > > > with a particular mesage bar at media has already sent to 
> foo at media.
> > >
> > > Thanks!
> > >
> > > Yes, this is precisely the kind of thing i'm looking for. 
>  I also need the
> > > ability to refer to the reply that foo sends, and I can't 
> really figure
> > > out how to do this without some non-standard crutch.
> > >
> > > Maybe a rough ascii diagram helps.
> > >
> >    [...snip...]
> >
> > Sean-
> >
> > I think you are struggling to find a solution to a problem 
> that doesn't
> > really exist. Since all Jabber messages arrive in order (at 
> least with
> > current server implementations), there is no need to know 
> explicitly that
> > a user sends two messages as a reply to a single message 
> from the other
> > end. It is implicit that if a message is sent by bar to 
> foo, and then foo
> > sends two responses on the same <thread>, they are 
> obviously "replying" to
> > the original message by bar. In addition, id numbers used 
> in most clients
> > don't relate directly to conversations. Most client 
> libraries will simply
> > increase the value of the id each time a packet is sent. id's are
> > generally not intended for this purpose. In fact, there is 
> no guarantee
> > that other clients will behave in the way you have 
> described, and I would
> > even go so far as to venture a guess that very few currently do.
> >
> > For example, considering the following exchange:
> >
> > 1) foo sends a message to bar with id='1'
> > 2) bar replies to message from foo without an id
> > 3) foo sends an iq request in iq:register to component x with id='2'
> > 4) foo replies to message from bar with id='3'
> > 5) component x sends iq result to foo with id='2'
> > 6) bar replies to message from foo without an id
> >
> > ... etc.
> >
> > You'll notice that bar does not use id's in its message 
> packets. This
> > behavior can be expected, because it is considered an 
> optional attribute
> > in the spec. (see: 
> http://jabber.org/ietf/draft-miller-xmpp-core-00.txt)
> >
> > Basically, for the purposes of message threading, the 
> <thread> element is
> > the appropriate feature of the protocol to use. If this is 
> insufficient
> > for your needs, I suggest you look at JEP-0033. While this 
> JEP is still
> > experimental, it would provide you with the functionality 
> you need and
> > would save you from trying to overload another feature of 
> the protocol,
> > which could cause incompatibilities and issues with some clients.
> >
> > See JEP-0033: http://jabber.org/jeps/jep-0033.html
> >
> > Cheers,
> >
> > bs.
> >
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> >
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>