[JDEV] id attr in message packets

[Sean Wheeler]

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
>