Hal Rottenberg wrote:
On 9/5/05, Trejkaz <[EMAIL PROTECTED]> wrote:FWIW, it would be better to use message IDs than timestamps. Those demos highlight the problem reasonably well: when you have multiple messages at the same time and someone replies to one message, you can't tell which message they replied to. Switch to message IDs, and come up with some extension element, and this would work *in theory*.Are thread IDs allowed in MUC messages?
Yes.
If they were, and if the
server and clients actually generated and preserved them, it would be
a relatively simple matter on the client-side to do as you say TX.
id1 + original message
- first timestamped reply with thread ID 1
- second timestamped reply with thread ID 1
id2 + and so on...
I don't see earth-shattering blockers to this...if the clients did
thread IDs of course (which we talked about several days ago).
Quite a separate issue, yes. But does this person who wants to institute a "clock system" plan to build a special application to do this, or does he plan to re-use existing clients and hope that they all support it? The challenge is that we'd be overloading the message ID to do this (presumably the MUC room would add the IDs) and not all clients would recognize those IDs (or the thread IDs). If clients recognize the message IDs, they could also include an In-Reply-To SHIM header as described in JEP-0131 and include the message ID there.
Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
