Reformatted excerpts from Grant Hollingworth''s message of
2008-01-16:> 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.
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>