
Hi Stephen,
Thank you so much for your email.
On Thu, 17 Oct 2024 at 17:43, Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> wrote:
Marco van Tol writes:
I tried this, and everything works fine with the last version of my script, except for one sort-of minor thing,
Please don't deprecate your requirements. If you need it, and you do:
Fair enough :)
It would be a minor thing if I hadn't told people this is the way to find out the number of messages in a list, and also to find the most recent post to a list.
we want to give it to you. Sure, sometimes it is harder than you imagine or in our judgment it's not worth as much as something else we could do, but you needn't be shy about asking for it. I'm also pretty sure it's hardly a unique requirement, at least it won't be for long, between GDPR and other worries about privacy of archived data in many contexts.
I hadn't thought about that one yet, but indeed, thank you.
[And what's not working right is] the message count if you search for "*". It won't update to the right message count in the top middle of the page until I do a "rebuild_index".
How much does time does cost to do that? If it's expensive enough that on "monthly cleaning day" you've got some lists that stay unsynced for many minutes or hours, we might need to rearchitect the index to be per list.
At the moment the entire list server has roughly 300.000 messages. From memory last time it took slightly under an hour.
A 300.000 count is a lot less than others have, but it makes it sort of okay for our server, today. If we time it right.
It is a 24x7 service though, so even at the best timing there's risk for a few people to have degraded service on the archives while the index rebuilds. But right now I think if we time it right once per month it's probably okay.
It would be nice if an improvement would be somewhere on a list of nice-to-haves. Or perhaps that list just only gets longer, it may well. :-)
I'm afraid "update" index only looks at the messages changed since the last
time update was run, and misses the fact that messages have disappeared from the beginning.
Have you looked at the code to verify this? I agree it's consistent with the Mailman behavior you see. Unfortunately I'm not sure that all the indexers we claim to support would be able to suppose such deletions without a full rebuild.
I have not verified it in the code, I aim to have a look at some point. Indeed I was writing this with the witnessed behaviour in mind.
Thanks Stephen!
Marco van Tol RIPE NCC