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]>
> 
> The looong logic just to access the paired repository. :-)
> 
> Of course, we should not try to go from one side to the other. This
> makes this patch unlikely to get merged.... BUT OTOH I understand this
> could help, offlineimap is getting old and Py2 will be deprecated soon
> enough.
> 

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.

By the way, what is the plan for py3? I remember there was pull request at
some point.

>> +        try:
>> +            keywordmap = otherrepo.getkeywordmap()
>> +            #now flip the map, because we need to translate flags into IMAP keywords
>> +            reversed_keywordmap = dict(zip(keywordmap.itervalues(), keywordmap.iterkeys()))
>> +
>> +            #TODO check other calls to imaputil.flagsmaildir2imap()
>> +            flagstring = imaputil.flagsmaildir2imap(flags, reversed_keywordmap)
>> +        except NotImplementedError:
>> +            #are we doing IMAP-to-IMAP then? just fail
>> +            raise OfflineImapError(
>> +                'Error getting keywordmap', OfflineImapError.ERROR.MESSAGE)
>> +
> 
> Why? Gmail/IMAP or IMAP/IMAP is valid. Will this error break the current
> sync of the message or log offending lines? I wonder we should
> intentionally ignore this error.

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...

>> diff --git a/offlineimap/imaputil.py b/offlineimap/imaputil.py
>> index 39bd8d4..28067ef 100644
>> --- a/offlineimap/imaputil.py
>> +++ b/offlineimap/imaputil.py
>> @@ -211,13 +211,21 @@ def flagsimap2keywords(flagstring):
>>      serverflagset = set([flag for (flag, c) in flagmap])
>>      return imapflagset - serverflagset
>>  
>> -def flagsmaildir2imap(maildirflaglist):
>> +def flagsmaildir2imap(maildirflaglist, letters_to_keywords_map=dict()):
>>      """Convert set of flags ([DR]) into a string '(\\Deleted \\Draft)'."""
>>  
>>      retval = []
>>      for imapflag, maildirflag in flagmap:
>>          if maildirflag in maildirflaglist:
>>              retval.append(imapflag)
>> +
>> +    #use the additional dict now
>> +    if len(letters_to_keywords_map) > 0:
>> +        for flag in maildirflaglist:
>> +            if flag in letters_to_keywords_map:
>> +                retval.append(letters_to_keywords_map[flag])
>> +
>> +    #NOTE there might be a problem with spaces in the keywordmap
> 
> Not very cool.
> 

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`.

>>      return '(' + ' '.join(sorted(retval)) + ')'
>>  
>>  def uid_sequence(uidlist):
> 
> Thanks!
> 
> -- 
> 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.