Quoth Gaute Hope on Aug 06 at 11:02 am: > On Fri, Aug 1, 2014 at 8:55 PM, Austin Clements <amdragon@mit.edu> wrote: > > I have a prototype implementation of message modification times on my > > lastmod-v1 branch at > > > > https://github.com/aclements/notmuch/tree/lastmod-v1 > > > > It builds on my database features series that's currently awaiting > > review [1]. > > > > The series uses a monotonic revision number, rather than wall-clock > > time, for reasons related to Xapian's concurrent control and detailed > > in the main commit's commit message. The implementation isn't quite > > useful from the CLI yet because I haven't added any way to query the > > database's current revision number. (I'm still thinking about how I > > want to do this, since search/show don't have a good way to deliver > > "additional" information right now. I might just add the last > > modification for each individual message/max of all messages in a > > thread, similar to what Thomas Jost's patch did long ago.) > > > > [1] id:1406859003-11561-1-git-send-email-amdragon@mit.edu > > > Hi, > > this should allow me to do what I wish to accomplish. The message > deletion is still a problem though, I can see two options at the moment: > > a) output during notmuch new to a hook or a list somewhere deleted files. > if list: notmuch will not handle this list, only append to it and > the user must > purge it when it is safe to do so. > > if hook: for my purposes I would just create a hook appending to the > list. as a minimum I think thread_id, message_id and revision number > should be included. > > > b) maintain a full list of deleted / dead messages. a user initiated > purge can clean this from the database. a tag could be used for this, > so that clients can ignore unlinked/deleted/dead messages. this > differs from a 'deleted' message (IMAP/Maildir context) that has not > yet been expunged so there is confusion to be avoided. > > a garbage collection function and interface must also be set up, but > this one is probably simple. > > > in most cases I think a) would be sufficient, and probably much easier > to do. it might be slow in cases where large amounts of messages have been > deleted, but this is seldom the case for me at least. I have a separate branch (also sitting on top of the features branch) that implements "ghost" messages. The main intent is to fix a bug we currently have in threading, but it puts us in a good position to maintain state for messages we don't have the content of, including last modification times for deleted messages and pre-seeded tags for undelivered messages (useful for pre-tagging sent messages as sent, nmbug, notmuch insert, etc.)