Re: [notmuch] Idea for storing tags

2010-01-14 Thread Carl Worth
On Thu, 14 Jan 2010 21:04:21 +1300, martin f krafft madd...@madduck.net wrote:
 You might have marked a message 'read' on one machine and if the two
 get out of sync on another machine, you might have the same message
 unread there.

That's a different issue though. With two databases there's clearly the
opportunity for the two databases to be out of synch.

But you talked about the database being out of synch with respect to the
mailstore. And that's something I just don't understand, (given the
assumption that all tags are stored in the database---which was the
explicit description of the case of interest).

 Shouldn't this just be solved? I've had formail+procmail delete my
 duplicates for 10+ years, and while I don't like the fact that
 I usually get the CC before the list mail, and thus cannot filter on
 Delivered-To, I have never looked back.

Notmuch has access to all the information it needs to allow you to
delete the CC version once the list mail arrives. So you could do
notmuch-based deletion now and avoid losing the Delivered-To header if
you want.

  [*] Though, I think a plain-text file with tags managed with
  something like git (and perhaps a custom merger) could save a lot
  of work. Or perhaps a plain-text journal of tag manipulations on
  either end that could be replayed on the other.
 
 Git is good at conflict resolution if run interactively, but [0]
 still makes me question whether it can ever take the place of IMAP.
 However, Asheesh Laroia, who has floated the idea of Git-for-mail at
 DebConf8 already, has some ideas and hopefully will soon reply to my
 mail [0], which I just bounced.
 
 0. http://notmuchmail.org/pipermail/notmuch/2010/001114.html

Using git for mail is an interesting idea, but not what I was actually
proposing here.

I think that synchronizing the mail store and synchronizing the tags
information are tasks that have different requirements, and for which we
may well want different tools.

So I was talking about using imap (or rsync, or what have you) for
copying the mailtstore, and then having something with a bit more
domain-specific awareness for doing the synchronization of the tags
data.

-Carl


pgpiO4aGHApgV.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] Idea for storing tags

2010-01-14 Thread martin f krafft
also sprach Carl Worth cwo...@cworth.org [2010.01.15.1124 +1300]:
  You might have marked a message 'read' on one machine and if the two
  get out of sync on another machine, you might have the same message
  unread there.
 
 That's a different issue though. With two databases there's clearly the
 opportunity for the two databases to be out of synch.
 
 But you talked about the database being out of synch with respect to the
 mailstore. And that's something I just don't understand, (given the
 assumption that all tags are stored in the database---which was the
 explicit description of the case of interest).

Yes, we are talking about the situation where the tagstore is
seperate from the mailstore, and that they are both synchronised
with a server, or between machines, separately. If for some reason
you only synchronise the mailstore — say because the connection
drops before the sync of the tagstore completes — then you end up
with an out-of-sync situation, because the mailstore-sync will have
pulled in a new message, but not the associated tags. So if you had
already read this message on another machine and tagged it 'done',
then it would show up on this machine as 'new' without the 'done'
tag, because the tags were not synchronised.

The only way to really solve this is by transferring a message and
its tags in a transactional way.

  Shouldn't this just be solved? I've had formail+procmail delete my
  duplicates for 10+ years, and while I don't like the fact that
  I usually get the CC before the list mail, and thus cannot filter on
  Delivered-To, I have never looked back.
 
 Notmuch has access to all the information it needs to allow you to
 delete the CC version once the list mail arrives. So you could do
 notmuch-based deletion now and avoid losing the Delivered-To header if
 you want.

Of course. I hadn't thought that far.

However, there are still benefits to formail, namely avoiding having
to run duplicates through potentially expensive spamfilters.

 I think that synchronizing the mail store and synchronizing the
 tags information are tasks that have different requirements, and
 for which we may well want different tools.

Fair enough. Maybe I am just paranoid about the stores getting out
of sync (see above).

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
we all know linux is great...
 it does infinite loops in 5 seconds.
 -- linus torvalds
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [notmuch] Idea for storing tags

2010-01-13 Thread Carl Worth
On Wed, 13 Jan 2010 00:39:14 -0500, Scott Morrison sm...@indev.ca wrote:
  Maybe a better approach would be content addressing (see below).
 
 Content hashing -- good Idea ( not something that has hit me before)
 -- better than Message-Id as I believe there are still some MUA /MTAs
 that allow messages without message ids.  The only potential issue
 with this is that it is critical then to preserve the message source
 against encoding changes though that shouldn't be too hard to avoid.

Another problem with content-based naming for messages is that most of
the messages in my mail store that I consider duplicates don't actually
have identical content. (One is sent directly to me via CC and the other
is sent by the mailing-list software *after* appending a footer to the
message.)

That said, notmuch already does use a sha-1 sum as the message
identifier for any message that does not have a valid Message-ID
header. So there's definitely a place for this.

-Carl


pgpc0PE5MY7sx.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch