* [sup-talk] Handling of messages appearing on multiple sources
@ 2008-11-24 17:31 Eduardo Habkost
[not found] ` <1227647755-sup-3231@ausone.local>
0 siblings, 1 reply; 4+ messages in thread
From: Eduardo Habkost @ 2008-11-24 17:31 UTC (permalink / raw)
Hi,
Currently, what is the expected behavior when a message appear on multiple
sources? Sometimes messages are sent to many different mailing lists
and end up on different mailboxes, and I would like those messages to
have the labels from both sources applied to them. Is it possible?
It would be nice if sup-tweak-labels and other utilities that deal with
messages on a per-source basis were aware that the message appeared on
multiple sources, also.
--
Eduardo
^ permalink raw reply [flat|nested] 4+ messages in thread
* [sup-talk] Handling of messages appearing on multiple sources
[not found] ` <1227647755-sup-3231@ausone.local>
@ 2008-11-26 21:35 ` Eduardo Habkost
2008-11-26 23:31 ` William Morgan
0 siblings, 1 reply; 4+ messages in thread
From: Eduardo Habkost @ 2008-11-26 21:35 UTC (permalink / raw)
On Tue, Nov 25, 2008 at 10:19:38PM +0100, Nicolas Pouillard wrote:
> Excerpts from Eduardo Habkost's message of Mon Nov 24 18:31:01 +0100 2008:
> >
> > Hi,
> Hi,
>
> > Currently, what is the expected behavior when a message appear on multiple
> > sources? Sometimes messages are sent to many different mailing lists
> > and end up on different mailboxes, and I would like those messages to
> > have the labels from both sources applied to them. Is it possible?
> >
> > It would be nice if sup-tweak-labels and other utilities that deal with
> > messages on a per-source basis were aware that the message appeared on
> > multiple sources, also.
>
> If it's the same message id, it should be shared.
When testing it here, I got the following:
Source 1 is the lkml source. Source 2 is the kvm-devel source. Some
messages are posted to both mailing lists and end up on both sources.
A message appearing only on kvm-devel is imported normally:
Adding message maildir:/home/ehabkost/mail/kvm-devel-l/#12277020930025949 with state {kvm-devel, unread, inbox}
A message appearing on both sources is imported this way:
Updating message maildir:/home/ehabkost/mail/kvm-devel-l/#12277021040004976, source 1 => 2, offset 12277036400004673 => 12277021040004976, state {lkml, unread, inbox} => {lkml, unread, inbox}
On this case, I would like the kvm-devel label to be applied to the
message, also.
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?
Handling the inbox label may be more complicated to implement properly
(especially if some of the sources have the 'archive' flag set and
some don't). 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).
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.
--
Eduardo
^ permalink raw reply [flat|nested] 4+ messages in thread
* [sup-talk] Handling of messages appearing on multiple sources
2008-11-26 21:35 ` Eduardo Habkost
@ 2008-11-26 23:31 ` William Morgan
2008-11-27 13:46 ` Eduardo Habkost
0 siblings, 1 reply; 4+ messages in thread
From: William Morgan @ 2008-11-26 23:31 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [sup-talk] Handling of messages appearing on multiple sources
2008-11-26 23:31 ` William Morgan
@ 2008-11-27 13:46 ` Eduardo Habkost
0 siblings, 0 replies; 4+ messages in thread
From: Eduardo Habkost @ 2008-11-27 13:46 UTC (permalink / raw)
Excerpts from William Morgan's message of Qua Nov 26 21:31:27 -0200 2008:
> 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.
It doesn't discard previous index state, currently. The problem is the
inverse: it uses the previous index state and doesn't add any other
label to an alrady indexed message.
>
> Can you try the attached patch and see if it fixes the problem?
It seems to do exactly what I want for new messages, but won't it break
the ability to keep unread/inbox state unchanged if I use --all on
sup-sync? I wouldn't like to all my archived messages to pop on inbox
again if I specify --all. Sometimes I specify --all because messages
were moved between sources, but I want to keep their archived/read state.
>
> > 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.
On the specific case of a message delivered to multiple sources, I
agree. But if messages were just moved or copied between mailboxes,
the user may want to keep the current archived/unread state. Actually,
the archived/read state is currently the most important data the Sup
index carries for me.
Ouch, that's complicated. 8)
I think the problem here is that the unread/inbox labels are special
in a way: for most labels, I don't care if Sup adds them to my messages
in addition to the current labels. But I would really care if the
inbox/unread labels were re-added to my messages when I didn't expect it.
Maybe this could be solved by forcing the user to be extra careful when
moving messages between sources. But the current ability to simply move
messages around and just use --all on sup-sync is a killer feature to
me. I wouldn't like to break it.
>
> > 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.
However, having some sort of message-id-based state seems to be useful
for backing up and restoring state or when moving messages between
sources, because it is the only thing that identify messages when they
are moved around.
The way it is implemented can change, but as an user I like the way sup
presents messages with the same message-id as a single entity. Even if
stored on different places or having some differences, they are the same
message, after all.
--
Eduardo
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-11-27 13:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-24 17:31 [sup-talk] Handling of messages appearing on multiple sources Eduardo Habkost
[not found] ` <1227647755-sup-3231@ausone.local>
2008-11-26 21:35 ` Eduardo Habkost
2008-11-26 23:31 ` William Morgan
2008-11-27 13:46 ` Eduardo Habkost
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox