Archive of RubyForge sup-talk mailing list
 help / color / mirror / Atom feed
From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] labels for updated messages
Date: Sat, 19 Jan 2008 09:18:13 -0800	[thread overview]
Message-ID: <1200761079-sup-3213@south> (raw)
In-Reply-To: <1200504528-sup-4009@spooky.local>

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>


      reply	other threads:[~2008-01-19 17:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-16 17:38 Grant Hollingworth
2008-01-19 17:18 ` William Morgan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1200761079-sup-3213@south \
    --to=wmorgan-sup@masanjin.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox