[jdev] Clock system to fallow discussion

[Trejkaz]

On Mon, 5 Sep 2005 22:56, Hal Rottenberg wrote:
> On 9/5/05, Trejkaz <trejkaz at trypticon.org> 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?  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).

Actually, the thread ID won't do, because you're supposed to use the same 
thread ID for the entire conversation.  To apply this to groupchats, every 
message in the entire groupchat would have the same thread ID (except from 
clients which don't support the feature, which would leave it out.)

And you know, even the stanza IDs might not be unique.  They are unique for 
one person's connection to the server, but if a few clients with the same ID 
generation algorithm are in the same room, the odds of seeing duplicates 
start rising rapidly.

Also, GUI-wise it would be a hassle, but I guess users would have to click on 
the line they're replying to.  And most users will be too lazy to do it.

It seems like it would be more productive to write an AI which can somehow 
figure out which messages go with which. ;-)

TX

-- 
             Email: Trejkaz Xaoza <trejkaz at trypticon.org>
          Web site: http://trypticon.org/
         Jabber ID: trejkaz at jabber.zim.net.au
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20050906/06fd32ef/attachment-0002.pgp>