Re: Status of version 5?

[Hans-Christian Prytz <hp@xxxxxxxxx>]

John Goerzen wrote:

>On Thu, Dec 11, 2003 at 04:00:55PM +0100, Hans-Christian Prytz wrote:
>  
>
>>>As for nnimap, I don't plan to implement that myself.  However, I would
>>>be pleased to apply a repository/nnmaildir.py and folder/nnmaildir.py
>>>patch to the source tree.
>>>
>>>      
>>>
>>Pity. Unfortunately I don't know python, nor du I hva the time to learn 
>>(wish I did) so I probably won't be of much help here.
>>    
>>
>
>Well, the main reason I wrote OfflineIMAP was because I loved the
>features of Gnus, but considered it too slow and buggy to use, I'm
>probably not going to be using it again anytime soon :-)
>
>  
>

Pity, Gnus is great, but you are right that imap within gnus is too slow.

>Unless it is really easy to support nnmaildir... (I really don't kow
>how it works; if it's only trivially different than what we do now, that
>would be doable.)
>
>Python is not hard to learn; if you already grok a couple of programming
>languages, especially object-oriented ones, you can probably pick it up
>in an hour or two.  Grokking Twisted and IMAP actually take longer, I
>think.  :-)
>
>  
>

I have looked into it a bit, and I won't have time to both learn Python 
and the layout of your program :-(

However I hvae looked into how nnimap stores it's marks, and what would 
be needed to preserve the normal (only really need read/unread) marks.
It really is surprisingly simple. Given a filename for a message in form 
"uniq:marks" in the normal cur/ directory within a maildir folder, 
nnimap stores marks as seperate file within subfolders of .nnmaildir/
In other words, if the mail "uniq:marks" was read in gnus, the following 
file would be created:
.nnmaildir/marks/read/uniq

An example from my INBOX (I've cut out parts):
hcpr@pc1864ws INBOX $ ls
cur  new  tmp
hcpr@pc1864ws INBOX $ ls cur
1072103688_0.21845.pc1864ws,U=2048,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
1072103688_1.21846.pc1864ws,U=2054,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
1072103688_2.21847.pc1864ws,U=2055,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
1072103689_0.21848.pc1864ws,U=2058,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S
......

hcpr@pc1864ws INBOX $ ls .nnmaildir/marks/read/
1072103688_0.21845.pc1864ws,U=2048,FMD5=7e33429f656f1e6e9d79b29c3f82c57e
1072103688_1.21846.pc1864ws,U=2054,FMD5=7e33429f656f1e6e9d79b29c3f82c57e
1072103688_2.21847.pc1864ws,U=2055,FMD5=7e33429f656f1e6e9d79b29c3f82c57e
1072103689_0.21848.pc1864ws,U=2058,FMD5=7e33429f656f1e6e9d79b29c3f82c57e
.....

In other words these four messages are read.

So if I understand this correctly, Offlineimap would have to check for 
".nnmaildir/marks/read/cur" to see if a given message is read or not. 
And vice-versa when writing new messages into a maildir.

I have tested this (briefly) manually by deleting a file in the 
marks/read folder, and the mail did show up as unread the next time I 
refreshed gnus.

Would this be a difficult thing to implement? I can help test it.

Hans-Christian