Re: <DKIM> [PATCH] Write IMAP keyword changes (maildir file renames) back to the server

Igor Almeida <[email protected]>
Newsgroups gmane.mail.imap.offlineimap.general
Message-ID <[email protected]>
Excerpts from Nicolas Sebrecht's message of May 19, 2019 11:24 am:
> On Sun, May 19, 2019 at 01:27:13AM -0300, Igor Almeida wrote:
> 
>> Yeah, I had to do some digging to find this. But the patch was mostly for
>> testing and feedback. And to remember the discussion we had a few years ago (!)
>> about eventually getting to this part.
>> 
>> For example, at some point we talked about checking PERMANENTFLAGS for
>> permission to store keywords and create new ones, but I don't understand the
>> protocol (and the code) enough to find where this would go.
> 
> I couldn't find this discussion.
> 

How do I refer to it? Message-IDs?

<[email protected]>
<[email protected]>

>> By the way, what is the plan for py3? I remember there was pull request at
>> some point.
> 
> Yes, there's been 3 attemps to port offlineimap to py3. All failed.
> 

Ouch.

>> It will break, yes.
>> If the source side is IMAP too, we enter the except block. At this point we could
>> set `flagstring` to `imaputil.flagsmaildir2imap(flags))`, which would revert
>> to the original code.
>> Also, if both servers are modern enough, there shouldn't be a need for
>> translating between their keyword representations...
> 
> I didn't check what would be the best. Why coulnd't just ignore this
> error?
> 

Yes, the except block should not fail as it does now.
I don't intend to test IMAP-IMAP sync, though.

>> Well, at least RF3501 says that `flag-keyword` (itself an `atom`) cannot have a
>> space... Anyway, to prevent a problem here, maybe when assembling the keywordmap
>> in MaildirRepository we could raise an error.
>> 
>> I don't particularly like passing the dict to this imaputil function. Maybe it
>> would be best to just add to the set after `imaputil.flagsmaildir2imap`
>> returns to `IMAPFolder.__processmessagesflags_real`.
> 
> I think that raising an error should be good enough. At least, this
> would stop the current process and avoid doing weird things.
> 

Great. I'll submit a v2 patch eventually.

BR

> 
> -- 
> Nicolas Sebrecht
> 

--
Igor Almeida

_______________________________________________
OfflineIMAP-project mailing list: [email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/offlineimap-project

OfflineIMAP homepages:
- https://github.com/OfflineIMAP
- http://offlineimap.org
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.