From: Daniel Kahn Gillmor Date: Fri, 1 Apr 2016 22:27:03 +0000 (+2100) Subject: Re: [PATCH] test thread breakage when messages are removed and re-added X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=6b446217cb3845b2babde9d2af894c190b7d8cce;p=notmuch-archives.git Re: [PATCH] test thread breakage when messages are removed and re-added --- diff --git a/f6/1c53c4dc9596949f7d5eef81aa2c973551b4ac b/f6/1c53c4dc9596949f7d5eef81aa2c973551b4ac new file mode 100644 index 000000000..7163ccd2d --- /dev/null +++ b/f6/1c53c4dc9596949f7d5eef81aa2c973551b4ac @@ -0,0 +1,123 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by arlo.cworth.org (Postfix) with ESMTP id CA7D36DE0243 + for ; Fri, 1 Apr 2016 18:50:21 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at cworth.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from arlo.cworth.org ([127.0.0.1]) + by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 5IbO_3VX6i4Y for ; + Fri, 1 Apr 2016 18:50:13 -0700 (PDT) +Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) + by arlo.cworth.org (Postfix) with ESMTP id 97AA26DE00DF + for ; Fri, 1 Apr 2016 18:50:13 -0700 (PDT) +Received: from fifthhorseman.net (unknown [190.172.4.74]) + by che.mayfirst.org (Postfix) with ESMTPSA id 4E774F99D + for ; Fri, 1 Apr 2016 21:50:11 -0400 (EDT) +Received: by fifthhorseman.net (Postfix, from userid 1000) + id BCA862059B; Fri, 1 Apr 2016 19:27:07 -0300 (BRT) +From: Daniel Kahn Gillmor +To: Notmuch Mail +Subject: Re: [PATCH] test thread breakage when messages are removed and + re-added +In-Reply-To: <1459445693-3900-1-git-send-email-dkg@fifthhorseman.net> +References: <1459445693-3900-1-git-send-email-dkg@fifthhorseman.net> +User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1 + (x86_64-pc-linux-gnu) +Date: Fri, 01 Apr 2016 19:27:03 -0300 +Message-ID: <8737r5dky0.fsf@alice.fifthhorseman.net> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha512; protocol="application/pgp-signature" +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.20 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sat, 02 Apr 2016 01:50:21 -0000 + +--=-=-= +Content-Type: text/plain + +On Thu 2016-03-31 14:34:53 -0300, Daniel Kahn Gillmor wrote: +> ghost-on-removal +> ---------------- +> +> We could unilaterally add a ghost upon message removal. This has a +> few disadvantages: the message index would leak information about what +> messages the user has ever been exposed to, and we also create a +> perpetually-growing dataset -- the ghosts can never be removed. +> +> ghost-on-removal-when-shared-thread-exists +> ------------------------------------------ +> +> We could add a ghost upon message removal iff there are other +> non-ghost messages with the same thread ID. +> +> We'd also need to remove all ghost messages that share a thread when +> the last non-ghost message in that thread is removed. +> +> This still has a bit of information leakage, though: the message index +> would reveal that i've seen a newer message in a thread, even if i had +> deleted it from my message store + +One more proposal along these lines: + +track-non-ghost-count-per-thread +-------------------------------- + +If each thread had a count of all the non-ghost messages associated with +it, and that count was properly maintained by the database, then upon +message deletion you would decrement the count. when that count reached +zero, you could destroy the thread. + +This has the same metadata leakage as +ghost-on-removal-when-shared-thread-exists, but i think it might be more +efficient, if we can cope with the denormalized database. + +This does have the downside of needing a database transition, though: +we'd have to add this count to all threads in a database upgrade. + + + +What do people think of the different options? what do you prefer? is +there some better approach that i've missed? + + --dkg + +--=-=-= +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2 + +iQJ8BAEBCgBmBQJW/vW3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy +NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKBFwP/3fiBCcA2W5KWe4R02JtO7qg +IuekGdsb95+HfauCrfdY5QQgSRmd6uIMniJkyZ9Zj4ccKEjPLDJ3nqn2M2xBHOzM +4j0b4CHmnhDZkNZAKgQCBjMMJVJ1qm4tTV380p1GOyChvQdxEHAelM3tT18rK/22 +ynmBJ8bCzMJ4RjG1rfLWqc9DA78AZCVxPj2Ikc+jKBRFc6UvdtOq5/dCgkykOfTV +lXFvO1BWwkH/6E9xijg7bl6sMGUsJzdLq0Jc5pTRYCyAMMv5DQlj1JllvQAXKYCO +9v8ZVYCOPHrCF4BMrBldmOhK+aghbzYYzhLG77PKqwr0l2XsOtvwwD6A1L4Lo26O +vCY8sZUVWfzzL7hnvRaJhLxCiiTObjhN8GtpG/QpsQmOLw7uxbtIWx8OnDRmdQMJ +pWjjNyDFdvbw/3fogUoGpUHxB28cyDQ/rvASNDgE1pOQWkD1BM7fMShcc7F0g+tn +mpxpmmawFqrWA1pYiral/NL6MyPSIGWLZNfL0fYJbgX0aKB2Dpl4l+Pa4ZmbIxX1 +bKkMahrQdoTPZOD4LmUov2aRSl4vMXjnJIlaHRqX70xk/E/dpkRA64XMNSAKtaCt +h5kYUNF4XnUUsEiknZYALCZfPmbMNfLw8GTJ+lGjEJRfGUBqBmh884SEcAklpOxi +JGbYC7K7Dr/IY75zMVMj +=TWtC +-----END PGP SIGNATURE----- +--=-=-=--