Subject: [sup-talk] labels for updated messages

From: [email-masked] (Grant Hollingworth)
Date: Wed, 16 Jan 2008 12:38:22 -0500

When a message is updated, source labels are not applied to it.

PollManager.do_poll:
  add_messages_from source do |m, offset, entry|
    ## always preserve the labels on disk.
    m.labels = entry[:label].split(/\s+/).map { |x| x.intern } if entry

This means that when I write to a mailing list, the message never gets a list
label applied, even when the message is updated from a source for that list.
The thread will be missing its label unless someone replies to my message.

The code above could merge in the source labels. It seems to me that it would
be uncommon to remove a label only to have it re-added when the message is
updated. It still bugs me to leave that unaddressed, though. We could keep
track of deleted labels, but that seems like a lot of work for an uncommon
situation.

---

From: [email-masked] (William Morgan)
Date: Sat, 19 Jan 2008 09:18:13 -0800

Reformatted excerpts from Grant Hollingworth's message of 2008-01-16:
> This means that when I write to a mailing list, the message never gets
> a list label applied, even when the message is updated from a source
> for that list.  The thread will be missing its label unless someone
> replies to my message.

This is a good point, and it's related to the broader question of, when
multiple different copies of a message, which should take precedence?
(In addition to having different automatically-assigned labels, the
subject may be rewritten by the list, list signatures may be added,
etc.)

The obvious answer is that later messages should supercede earlier ones,
and I think that's what most MUAs do. Regardless, we definitely need to
merge labels so that we don't lose user information.

What is tricky in our case is that sup-sync may be called to reprocess a
source containing an older copy of the message. We then have two
options:

1. Oh well. If you reprocess an older message, you'll get its version,
   and you just have to be aware of it.
2. Keep the arrival time of each message in the index, and guarantee the
   later-supercedes-earlier behavior described above.

I'm leaning towards #1, since it's less work. :)

> The code above could merge in the source labels. It seems to me that
> it would be uncommon to remove a label only to have it re-added when
> the message is updated. It still bugs me to leave that unaddressed,
> though. We could keep track of deleted labels, but that seems like a
> lot of work for an uncommon situation.

I'm having a hard time imagining what the situation in which a label
would be re-added would even look like. Something like: you send a
message to a list, tag it with the label that is automatically applied
to messages of that list, but then decide to remove that label, only to
have it readded when the ML copy arrives? Seems pretty unlikely.

-- 
William <wmorgan-sup at masanjin.net>