Konstantin Ryabitsev <[email protected]> wrote: > On Mon, Mar 27, 2023 at 07:10:49PM +0000, Eric Wong wrote: > > > For the bugzilla integration work I'm doing, I need a way to check if > > > there > > > were any updates to a thread since the last check. Right now, I'm just > > > grabbing the full thread, parsing it and seeing if there are any new > > > message-IDs that we don't know about, but it's very wasteful. Any way to > > > just > > > issue something like "how many messages are in a thread with this > > > message-id" > > > or "are there any updates to a thread with this message-id since > > > YYYYMMDDHHMMSS? > > > > lei q -t --only /path/to/(inbox|extindex) mid:$MSGID rt:APPROXIDATE.. > > > > Returns JSON and won't retrieve message bodies from git. > > Ah, I was hoping to have a fully remote way of doing this. > > > I wouldn't query down to the second due to propagation delays, > > clock skew, etc, though. > > > > There might be a JMAP endpoint I can implement for WWW which > > only retrieves that info, but getting backreferences (required > > by the JMAP spec) to work properly seemed painful. > > What about a "bodiless" atom feed? It's already available per thread, so > perhaps there could be a mode that skips the bodies or trims them after the > first paragraph?
I thought about that, too; but I'm worried about having one-off stuff that ends up needing to be supported indefinitely. JMAP for this would take more time, but I'd be more comfortable carrying it long-term. I don't expect trimming after the first paragraph to be a huge improvement. Retrieving any part of the message from git and dealing with MIME is expensive, anyways. I wouldn't expect it to be a big (if any) improvement compared to POST-ing for the mbox.gz (&x=m&t=1) endpoint with rt:$SINCE.. The mbox.gz endpoints should be a bit more efficient for the server than Atom feeds; decoding MIME and HTML escaping takes up considerable CPU time.
