On June 25, 2001 at 11:50, Eddie Kohler wrote:
Currently, if TREVERSE is true, TNEXT behaves as follows:
(1) If there is a chronologically next message in the current thread,
jump to it.
(2) Otherwise, jump to the chronologically PREVIOUS thread.
This analysis is incorrect. Chronology plays a secondary role when
it comes to threading. The linear listing order of a thread rarely
matches the actual chronological order of all messages in a thread.
Take for example:
message 1
message 2
message 3
message 4
message 5
message 6
message 7
"message 5" is not guaranteed to be newer than "message 3" or
"message 4, and it ususally is not. Therefore, when on "message 4",
hitting the "next in thread" link will take them to an older message,
"message 5".
Now, what you refer to as "chronologically PREVIOUS thread" is a matter
of perspective. With TREVERSE, only the root messages are considered.
However, some, if not most, users expected that a new message that goes
to a thread would bump the thread listing to the top of the index.
I.e. Root thread ordering would be based on the latest message in the
thread. However, this is not the case (since doing that would require
extra processing and slow things down). This is why I stated TREVERSE
is not always a good option since its behavior is not what some
expect. With MULTIPG, I figure it is mute since it easy to start at
the last page of index to see the "latest" messages (and a long time
ago a user posted a simple CGI to make the last page the default page
for an archive). Note, even this is not guaranteed with thread indexes
if the archive contains very long threads with the root message much
older than most messages.
This seems inconsistent to me. And I don't think there's any way, using
layout resources, to get the following behavior, which I want:
(1) If there is a chronologically next message in the current thread,
jump to it.
Again, this is not an accurate assessment since chronology is not
the primary key for thread sorting.
(2) Otherwise, jump to the chronologically NEXT thread.
This is a possible reasonable behavior, but can be considered
inconsistent with your logic. Since TNEXT within a thread can
go to an *older* message.
Recalling my thoughts of next/prev behavior, I went with the "flip"
concept for reverse data indexes since date is the primary key and
most people would think that way. However, since in a thread index,
date is secondary, I did no bother with it and requires extra overhead
computing tnext/tprev with questionable use. Nobody has complained
about it until now (excluding the TREVERSE behavior of index ordering
which is not the concern you are addressing).
5. Other orderings should follow the date ordering behavior lest
link behavior become inconsistent depending on index choice.
But, threads by nature follow a different ording.
I can argue that your change to TNEXT/TPREV is irrelevent since
TREVERSE itself does do what many users "intuitively" think it should
do (and that is the threads are ordered by the date of the latest
message in each thread). Hence, I typically discourage its usage.
In sum, I understand your reasoning, but since no one has really
commented about it (except yourself), I did not think it is worth the
performance overhead to implement it. TREVERSE behavior itself
is more of an issue, but would generally cause a big performance
impact to implement it in a way that may users would like.
BTW, in general, using any of the reverse options is not good for
performance if MULTIPG is active since any new message added will
generally cause a rewrite of all index pages, a big hit in
performance.
--ewh
