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@media" to="foo@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@media has already sent to foo@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 > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev > _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
