On 11/16/2010 03:44 PM, Jameson Rollins wrote: > Aren't clients going to have to interpret/display the output regardless > of it's been verified or not? It seems to me that understanding how to > display the verified output is really not that much more difficult than > understanding how to display the unverified output.
With json (and similar formats), it's easy to write a parser that says "i know what to do with data member $foo -- give me that one". This lets you remain in blissful ignorance of data members $bar and $baz. and if your backend suddenly starts throwing $qux at you as well, you can just ignore it too, until you find you want to make use of it. I imagine that someone writing a frontend would want to start with things like message display, and not bother with fancier bits (such as signature verification) until later. frontends that know that their backend is somehow resource constrained might also want to indicate to the user that a message claims to be signed but not verify the signature unless the user asks for it. (i wish my current MUA had that feature, actually -- some messages i get are signed but i don't personally need to verify them on every reload (or even ever), depending on their content, but my MUA always makes me wait for the verification process to happen. To be clear -- i think that signature verification should be the default situation for MUAs that are capable of doing it, but i don't think that translates into --verify being on by default in /usr/bin/notmuch. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101116/d0c860b9/attachment.pgp>