In our system we assign ids to messages, and messages can optionally have
parent ids. This allows for representing a hierarchical tree of messages in a
MUC. These ids are indicated with our own namespaced XML.
I'm trying to figure out how to make this nested messages stuff a little more
"standard". One idea is to use the <thread> element. Every message could
have a unique thread value, and use the parent attribute to specify parent
messages as necessary. Although this would work, the idea of every message
having a unique thread value runs counter to how <thread> is/was intended to
be used: sharing a thread value across many messages.
I also wonder about the best way to specify a parent when submitting a
comment. Would it be legal for a <thread> to have a parent attribute but no
text node?
I imagine a protocol like this:
Client submits message to MUC, specifying id of parent message (but notably
does NOT attempt to assert an id for itself)
<message to="muc">
<thread parent="1"/>
<body>I agree</body>
</message>
MUC assigns an id to the message (in this case, "2"), and echos back to
everyone in the room:
<message from="muc">
<thread parent="1">2</thread>
<body>I agree</body>
</message>
If this is a violation of how <thread> should be used, then I'd be interested
in alternative suggestions.
-Justin