[PATCH/RFC 1/7] New feature: Update folder structure to new config parameters.
nicolas.s-dev at laposte.net
Sun Mar 3 11:17:30 GMT 2019
On Sun, Mar 03, 2019 at 03:56:57AM -0500, Hubert Pineault wrote:
> If you change some of the config file paremeters, like nametrans
> and utf8 decode, it will completly mess your maildir folder
> structure. So, to make changes in config file, you need to
> re-download the whole imap account.
> If it weights a few gigs,
> it's a bit annoying. With the coming of features like remote
> folder creation and utf8 decoding of folder names, a converting
> tool could be handy for some of us.
You're trying to address two different goals:
1. gently moving to utf8 support
2. support nametrans updates
For (1) utf8, you're trying to address
which is not a small one. Great!
I've just updated this issue, BTW.
So, we might rather like to only support moving to UTF8 without going
back. In this case, we could introduce your new policy: create a new
config file, metadatadir and maildirs while avoiding re-downloads and
update everything is needed (md5, etc).
Something like --convert-to-utf8 could help to keep the code as simple
as possible. This way, the code about this UTF conversion might be moved
out from the syncing logic.
About (2) nametrans, we must take care about what we do. I still don't
understand how we would correctly map the old translated foldernames
to the new translated foldernames because it's tracked anywhere.
Suppose we have a IMAP folder "A" and there is a nametrans translating
"A" to "J". When we write a new nametrans translating "A" to "X", how do
we know that "X" is the new "J"? The only use case we know "X" is the
new "J" is when moving to UTF-8. BTW, this conversion can break the
nametrans by other means because matching rules for strings in UTF-7 and
UTF-8 can be distinct. I think this operation likely requires manual
checks from the user and we can't fully automate the process.
> The objectif is to convert an actual maildir folder structure to a
> new one. There is still a farely good amount of work to do in
> order to make it ready to merge with main branch. I have already
> identified some changes that should be made in the update
> process. Those points are raised in details related commits'
> messages. I will need some help with cleaning the code and,
> notably, exceptions handling.
> The three main points that will need a complete rewritting are:
> - The invoking method (actually, we load two independent config
> - The way different config parameters are handled by objects
> - (actually, we use two accounts, so two remote, local and status
> - Instead of altering existing class, it could be a better idea to
> create a child class specific for updating.
My first feeling after a quick review of this path series is that we
might really like to keep things as simple as possible. Currently,
the required changes are deep with a lot of duplication of code.
Converting the config file, metadata and maildirs from UTF-7 to UTF-8
could be one way and non-reversible. This would be fine if we agree on
your approach of duplicating all the local content to a full new setup.
The other good news is that I guess we could keep the sync and
conversion logic seperated. I think this would help us to keep the code
much more simple.
More information about the OfflineIMAP-project