From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] Handling of messages appearing on multiple sources
Date: Wed, 26 Nov 2008 15:31:27 -0800 [thread overview]
Message-ID: <1227740974-sup-6395@entry> (raw)
In-Reply-To: <20081126213523.GB4628@blackpad>
Reformatted excerpts from Eduardo Habkost's message of 2008-11-26:
> I would even argue that adding the tags configured for both sources
> should be the default, but I don't know if there are users relying on
> the current behavior, today. What do you think?
Actually, I think you're right. I don't know that there's a reason, at
least during normal operation, to discard previous index state.
Can you try the attached patch and see if it fixes the problem?
> But as an user, I expect that a message appearing on both a non-inbox
> source and an inbox source would get into the inbox. The problem would
> be handling a message appearing on an inbox source after the user have
> archived it. On this case, the user may expect the message to not
> appear on the inbox again (I am not sure what would be more
> intuitive).
Well, it's an ambiguous situation, and I'm generally happy in ambiguous
situations to take the simplest (to implement!) approach, which in this
case is to pop it back into the inbox.
> Additionally, I think it would be nice if sup were aware of when the
> message appears multiple times on the sources, instead of rewriting
> the source and offset fields. Most times the user doesn't need to be
> aware there are multiple versions of a message, but when checking
> message headers or other small details of messages coming from
> different paths, it would be useful to have both versions available.
I think I agree. STS (the apocryphal new version of Sup) probably won't
canonicalize by message id like Sup does.
--
William <wmorgan-sup at masanjin.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-for-duplicate-messages-merge-labels-rather-than-dis.patch
Type: application/octet-stream
Size: 1373 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20081126/857ef42d/attachment.obj>
next prev parent reply other threads:[~2008-11-26 23:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-24 17:31 Eduardo Habkost
[not found] ` <1227647755-sup-3231@ausone.local>
2008-11-26 21:35 ` Eduardo Habkost
2008-11-26 23:31 ` William Morgan [this message]
2008-11-27 13:46 ` Eduardo Habkost
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=1227740974-sup-6395@entry \
--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