On Tue 2016-05-31 21:52:06 -0400, Daniel Kahn Gillmor wrote: > Thanks for working on this, David! I think this is going to be really > useful! just thinking about this series this morning in a bigger-picture way, i figure it's worth asking the hard questions now rather than later -- maybe the answers are obvious, and we just need to write them down. Please accept these questions in the spirit of supportive inquiry :) Here goes: do we actually need this abstraction? If we're aiming to build specific new features (the two i'm thinking of are cryptographic-session-keys and reference-adjustments), couldn't we implement those features explicitly in xapian with their own special prefix, rather than treating them as a generic "property"? If we make a generic "property", that seems likely to be exposed to the user, who can then manipulate them directly externally from notmuch. We already have a bit of an uncomfortable fit with tags and special flags (encrypted, signed, attachment, etc), where some are expected to be set and cleared automagically and some are expected to be manipulated directly by the user. Are we setting ourselves up for more of the same, or is there a principled way that a user can know which properties it's kosher for them to set and clear, and which ones they should leave alone? If we add new specific features, we could potentially augment the dump format explicitly for them, without having the property abstraction. We already have some explicit features for each message (subject, from, to, attachment, mimetype, thread id, etc), and most of them are derived from the message itself, with the hope that it could be re-derived given just the message body. Is there a distinction between properties that can be derived from the message body and properties that need to be additionally derived from some other data? --dkg