Gmail support

Jim squibblyflabbetydoo at gmail.com
Fri Feb 21 18:01:29 UTC 2014


I don't think we need to worry about this too much; my plan is to do this
only for Gmail, which as far as I know de-duplicates on the server side, so
we should match that behavior. Otherwise, we're storing multiple copies of
messages that really *are* exact duplicates.

- Jim

On Fri, Feb 21, 2014 at 11:43 AM, Andrew J. Buehler <wanderer at fastmail.fm>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 02/20/2014 07:31 AM, Tanstaafl wrote:
>
> > On 2014-02-19 7:45 AM, Andrew J. Buehler <wanderer at fastmail.fm>
> > wrote:
>
> >> This is especially - or, at least, primarily - because last time I
> >> checked, they don't consider e.g. "the Sent-folder copy of a
> >> message I sent to a mailing list" and "the copy of the same message
> >> which I received from the mailing list, which has been modified by
> >> the mailing list software" to be different messages, even though
> >> their contents (e.g. list footers and message header information)
> >> are different.
> >
> > I don't see *any* reason to *ever* keep more than one *physical* copy
> > of any given message on the same mailstore, I absolutely agree with
> > you on the way GMail treats Sent messages. They are *not*, in fact,
> > the same message, so should *not* be de-duped like google does now.
> >
> > But other than that, I really like it's de-duplication feature.
>
> It's not just Sent messages, though.
>
> Say I post a message to a mailing list, and someone replies both to the
> list and directly to me.
>
> The copy of the reply which I receive through the list has been modified
> by the list software. The copy which I receive directly has not. They
> are not identical, and I want both versions - or at least to be able to
> decide for myself which, if either, to delete.
>
> Other scenarios are possible as well, where there will be multiple
> similar-but-different copies of a given message, with the same
> Message-ID; such messages are distinct, and should be treated as such.
> Reliably distinguishing between them for deduplication purposes, without
> having to essentially cmp every new message against every existing
> message (which seems likely to kill performance), would be - at best - a
> considerable challenge. The obvious approach would be to use a hash of
> the message, but that leaves open the potential for collisions.
>
>
> I'm having a hard time thinking of any example of a scenario where there
> would be multiple identical copies of a message in a given account,
> except where the user explicitly and/or actively copied the message into
> a second location - which I would expect to be rare.
>
> Deduplication in that case would be fine, I should think, but not pretty
> much any other. (And even that case has issues. What if the message has
> an attachment, and then the user chooses "remove attachment" on one
> copy? Should the attachment be removed from the other copy as well, or
> should the deduplication disappear?)
>
> I like the idea of deduplication within an account in theory, but in
> practice, I'm not sure the challenges don't far outweigh the advantages.
>
> - --
>   Andrew J. Buehler
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBCgAGBQJTB5BJAAoJEASpNY00KDJr/JEQAIocr18RpnVIUDKoIJgXg1U5
> bSHBUxdCTTxv5RP+J4k6E8y5RlHBEDJDHW6Aj38ACNbyd2he16uZsd/amnt12auC
> hA3iBj1qeFD1UKrcYMPs5b2d/+dbMJU0Bc2i93Cfr4wr0ZbssmB9HbwdkangJMkf
> wgR2mb/MPH11r834EQyauqSeZfcHFdrLkt0wgaGKsZeUj6Jme1IFxV3PIzSsLHkR
> aDQlfF0YwhIfzu9tI1ghOnyxEzeuRzyOcgjg/1AZhUma44WjpFEfWbLWo4zp57yA
> 3lUhGlEVYKmdfoRQxF4pBh6BMsRHho/9TCj8MVl/kv8qf/cEdKmV4Ze+/oHpjTas
> YhMWtwpymjXKDb+vHwnSTi2+jZbvFQJa6ggFFkHx6UVKNJuQZF0s+76VZN5BY61o
> FpXyqxpWF6U5nP8d0yfLhoSODGqFC24ZJ37u9w/E7VEJEomT33pj2t3KkuBcsjKN
> R78TyPRwrO/V+58cPc0GX73ablnhLN7Kw6S0ubYPk4wZq3HtOWJkloBLu1cbtfb9
> aUW87mA+LWUsRBiMjsBf4nN/4RF4zgaeN/wIPLN7g9CQIWnRmk+/NeUe/ucrf/Uv
> AZKavVUX3dwgRxv6iT68mlEGMvz/X3dQHi3eZNXyMFwkJsugHJquZgRDPzImEKuo
> S+t4an8OpN/73K08uSoe
> =0OrN
> -----END PGP SIGNATURE-----
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20140221/7025bad2/attachment.html>


More information about the tb-planning mailing list