Re: message threading in the web UI

[Ralph Siemsen <ralph.siemsen@linaro.org>]

On Fri, Nov 15, 2019 at 11:52:35PM +0000, Eric Wong wrote:
>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").

Ah, I see. Makes sense from a programmers point of view of course. 
However as an end user, based on what is shown in the UI, it looks like 
each thread is complete -- the number of messages in each thread varies 
(not artificially capped at say 5 messages per thread). When the thread 
consists of a patch series, the whole series seems to be displayed 
(likely because they are all posted together at the same time).

It is not very obvious that some additional messages (such as replies to 
the individual patches in a series) have been hidden. I only discovered 
it when I used my browser "Find in Page", and it did not find all the 
occurrences (but using "search" box on PI did find them).

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

Understood.

>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"

While those are a bit more obvious than just a "+" sign, to me at least, 
they are all ambiguous. The number itself is not really helping, since 
it is just a count of the number of lines that are displayed immediately 
below. In other words, the count does not add any information.

So perhaps just remove it entirely? For example:

[PATCH 0/3] start tidying up gzip-related code
 2019-11-16  2:34 UTC
` [PATCH 1/3] mbox: unused mid_clean import
` [PATCH 2/3] mbox: split mboxgz out into a separate file
` [PATCH 3/3] mboxgz: use Compress::Raw::Zlib instead of IO::Compress::Gzip
` <additional replies>

Note the extra line at the end, containing a link to the full thread. 
This essentially replaces the "+" with a more obvious indication that
messages have been omitted from the summary.

>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.

Caching the whole page, esp for LKML and the like, certainly makes 
sense, but that is a bigger task for sure.

Thanks for your reply!
-Ralph