Konstantin Ryabitsev <konstan...@linuxfoundation.org> wrote:
> I'm fine with either of these, and just to stress, it's not really blocking
> anything I'm working on -- bugbot is in initial rollout stages, so while the
> number of tracked bugs/threads remains low, even if we re-download a hundred
> threads every 10 minutes, it's just internal churn between two adjacent VMs.
> If it becomes heavy, I can always look into switching to lei and performing
> local queries instead of doing external polling.
Alright.
> However, if you do want to add ability to cheaply do a "give me just the
> newest messages in this thread since this datetime", that would be great for
> my needs. :)
Per-thread search is something I've wanted for a while, anyways,
so I think I'll do /$MSGID/?q= in between ongoing work for
codesearch and chasing down FreeBSD issues.
I may not expose /$MSGID/?q= it via HTML just yet since I find
<form> elements confusing as a user :x
Indexing References/IRT would be a waste of space and I/O due to
MUA truncations; so I'm hesitant to do it since we already index
THREADID.
thread:{sub-query} will be nice, but I'll get to it after I deal
with the lei FUSE stuff since I've already done most of the C
work from another project. Normal FSes are so inefficient
for storing Maildir outputs.
