[PATCH/RFC 1/7] New feature: Update folder structure to new config parameters.

[Nicolas Sebrecht]

On Mon, Mar 04, 2019 at 12:22:03AM -0500, Hubert Pineault wrote:

> Originally, I started this project because I had switched from an
> offlineimap version not supporting utf8foldername and reverse nametrans
> to the lastest version. I wanted to be able to apply utf8 names and the
> nametrans I was using on the old version were not thought to be
> reversible. More over, my email account was polluted by other email
> client, tests, etc. So I thought, it'd be a good idea to write a program
> to change folder name and merge folders. I was half way through and I
> thougth, hey why not try to do this from the source code. I'll send both
> config in an other mail to give you a better idea.

Ok.

> The way I see it. I'm not really adressing this issue. Well, I'm only
> doing half the job.
> What you mention in the discussion is three points:
>   1) The need to remember utf7 name from imap list command even if utf8
>   is enabled. This is what I'm doing in patch 5, for IMAPRepository.

There's no need to remember the previous name (utf7 or utf8) because
this can be easily computed.

>   2) To make the same thing with MaildirFolder and add a function to
>   make the conversion.
>   3) The main difficulty is to consider those two names as synonymes in
>   appropriate getfolders() methods. This patch is not dealing with this.

I don't get this. Actually, I'm not sure to get the current approach in
the code. My main point is that this seems over-complicated.

Supporting utf7 <-> utf8 conversion requires:

1. Detect if there's any change in the foldername.
2. If so, apply the updates (maildir, metadata).
3. Remove the dangling objects (maildirs, metadata for the previous
encoding).

I think that the nice way to do the job is to do all the above while
comparing the folder structure, not when we're about to sync the
folders. Anywhere else, the code is already compatible with both
encodings.

IOW, there should be no need to make changes so deep in the code to
support this feature. I see no need to duplicate code. Also, if we
remove the support for nametrans we don't have to support two config
files.

> This could be the subject of a first pull request. Although, I think
> this should be made having in mind a more complexe conversion process to
> include nametrans in a second pull request. So, I think we should take
> time to discuss my code before getting to this.

Agreed. Let's break the topic into utf7/utf8 and postpone nametrans
because they are not small changes.

-- 
Nicolas Sebrecht