On Wed Nov 10 19:17:48 2010, Justin Karneges wrote:
On Wednesday 10 November 2010 04:30:20 Dave Cridland wrote:
> If a client sends a chatroom a message, and that message has an
id,
> should outbound messages from the chatroom to the occupants use
the
> same id?
>
> Doing so has obvious implications on id uniqueness, but apparently
> most implementations preserve the id, and the result is that at
least
> one client implementation is relying on this behaviour.
>
> Personally, I consider the two stanzas - occupant to MUC, and MUC
to
> occupants - to be distinct, just having the same (or similar, at
> least) payloads - and therefore have different ids (indeed,
different
> per occupant). Everyone else seems to consider this a silly idea.
>
> I'll go along with whatever people think - but it's something
else to
> add to XEP-0045, whichever way people decide.
The other day in jdev we were discussing using message ids to
assist in
creating a hierarchical tree of messages within a MUC room. This
would mean
the MUC enforcing uniqueness of ids sent out to participants (so
that every
past message is uniquely identifiable), and then participants could
choose a
"parent" message id when sending new messages to the MUC room. So
this is at
least one use-case that would demand the MUC being able to rewrite
the id.
That's different *again*.
So there's at least there cases to ponder:
1) The id on the broadcast messages should be the same as the id on
the stanza sent to the MUC.
This appears to be what Prosody, Openfire, and Jabber XCP do. (Not
that I've tested personally).
2) The id on the broadcast messages is generated each time by the
MUC, hence all ids are different.
3) The id on the broadcast messages is the same for each broadcast,
but different to the id on the stanza sent to the MUC.
I think you're describing (3). I think that's sufficient for error
handling, but our contact wants (1), which breaks that too.
Personally, I think that in your case you want either a <thread/>, or
a more message-id-like element. (I think our id attributes map closer
to transaction identifiers than message identifiers).
Either has a more controlled lifetime, and is thus considerably more
reliable for most cases, as compared to an id which might be reused
on reconnect (or by a different client).
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
