Hi, In the last thread about mod_mbox (js speed and mbox_size, July 13th), we settled on a paged browsing for mod_mbox message list because of the size of a full message list (>500k for a 2000 messages mbox).
This currently works well with date and author sort because we know exactly how many messages we are going to display per page (#define DEFAULT_MSGS_PER_PAGE 100, soon configurable). But the thread sort brings a problem I was not yet able to fix. In order to be as consistant as possible, we do not want to break threads. It's also simpler since displaying a thread is a recursive call, only returning to the caller function when the full thread message list has been output. The problem comes when displaying DEFAULT_THREADS_PER_PAGE (#defined to 40 for the moment) outputs more than DEFAULT_MSGS_PER_AGE : we have one or more empty pages at the end. We could, of course, count how many messages a call to display_msglist_thread() outputs. But we would have to count twice : one for counting messages without displaying them in order to print the page switcher, and another time when displaying the messages. Both pass involve recursive and exhaustive traversal of the thread container structures. As I write, a possible solution appears to me : we could add a 'count' element to the Container datatype which contains the number of messages a Container actually contains. But I don't know yet if this is possible (depends on how the calculate_threads() function works). If you have any idea concerning this problem, or even an alternate, simpler or more efficient solution to paging, you are welcome to share it. - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message.
signature.asc
Description: Digital signature
