Re: message threading in the web UI

[Eric Wong <e@80x24.org>]

Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
> The way that threads are displayed seems to differ between the "frontpage"
> (eg. https://public-inbox.org/meta/) versus how they are shown in the
> "Thread Overview" (at the bottom of the page when viewing a specific
> thread).
> 
> On the frontpage, it seems only a subset of messages are displayed (maybe
> only the direct replies?). The only indication that there are additional
> hidden messages is the "+" sign, e.g. "(5+ messages)".

Yes, the frontpage only grabs the 200 most recent messages
(a "time window").

> In contrast when viewing a message thread, the "Thread Overview" at the
> bottom shows quite clearly the full thread (nothing seems to be hidden).

Right.  That's a separate SQLite query for every thread.

> Would it be possible to either:
> * unify the behaviour so it is the same in all places, or
> * in the "frontpage" make it more clear that threads are hidden,
>  for example change "(5+ messages)" to "N/M messages". Consider adding
>  a link ("rest of thread" or "additional replies") as a final element
>  for any "abbreviated" threads.
> 
> One might argue that "+" sign is sufficient indicator, but until you realize
> its significance, it is just noise. When I first saw it, I manually counted
> the messages, and compared that with "(5+ messages"). They nearly matched,
> so I assumed the "+" indicated that an exact value was not possible, for
> whatever reason.

Getting the exact value is possible, just more expensive...

> Anyhow, this is just my $0.02, but I though I'd pass it along.

Thanks for the feedback; and I agree, it's sometimes confusing :x

Getting the full count ("M") can be expensive since it needs an
SQLite COUNT query for every thread...

I'm not sure how feasable that is since frontpage performance is
critical and I spent a fair amount of time making it perform
acceptably for giant inboxes like LKML.

(Optionally) supporting Cache::FastMmap or other caching
mechanisms may help, but that's still extra install overhead and
initial load performance still needs to be taken into account.

Perhaps as an interim solution is to change the "+" for
something more obvious:

"5 or more messages"
"5 messages in current time window"
">= 5 messages"
"at least 5 messages"
...

Thoughts?