On Tue, Sep 07, 2021 at 08:56:17PM +0000, Eric Wong wrote: > > 1. this means that each "lei up" call will be increasingly larger and > > larger, > > since when we init the search with rt:, it gets resolved into a datestamp > > (e.g. rt:2.weeks.ago becomes rt:1625699031). I'm worried that this will > > be > > increasingly hard on the server side, especially if someone > > fires-and-forgets a cronjob that ends up downloading ever-growing mboxes > > every 5 minutes. > > "rt:2.weeks.ago" stays "rt:2.weeks.ago" in saved searches :>
Oh, you're right. Apologies for not digging deeper. > > 2. is there some sanity limit on the server side that would prevent > > someone's > > overly broad search query from gzipping and downloading gigabytes of > > mail? > > Not right now. With public-inbox-httpd, the actual git fetches > are handled fairly w.r.t to other requests (and I could > deprioritize them further, if needed...). The Xapian query OTOH... Okay, I guess it's not any different from someone doing the same thing over the web interface. It would be nice to have a way to limit how many messages are returned for gzipped mailbox downloads, seeing as they cannot be paginated in the same way web views are, but it's not a priority right away. Thanks, -K
