[PATCH 6/8] Re: Move self.folderfilter|nametrans|sort from IMAPFolder to BaseFolder

[Nicolas Sebrecht]

On Mon, Aug 29, 2011 at 04:00:15PM +0200, Sebastian Spaeth wrote:
> We want to have these functions available for Maildir folders too, so we
> can folderfilter a Maildir repository too (which is currently not possible)
> 
> This commit only move the corresponding functions from the IMAP to the Base
> implementation. It should not change behavior in any way yet.

So, you're betting on the fact that the two-ways nametrans is the best
approach. I'm not convinced, yet. There are "complex" concepts end-users
will have to deal with.

In case of a wrong nametrans rules, users may virtually have a lot of
wrong assumptions. Consequently, they'll be faced against a lot of way
to destroy/mix up their data. One I can think of, for example, would be
to have an infinite loop while applying both-sides nametrans, e.g.:

  cream (local) --become-> nice_cream (remote) --become-> ice_cream (local)
  --become-> nice_ice_cream (remote) --become-> etc...

What about "INBOX/cream" vs "cream". Let say someone creates "cream" on
local, apply a nametrans to appear as "INBOX/cream" to remote where it
shouldn't. On next run we get "INBOX/INBOX/cream", right? I'm afraid
this is a very _simple_ wrong usage.

Another example, a bit more complex, could be that the user _has_ a
virtual folder called "INBOX". So, the remote know "INBOX/INBOX"
rendered locally by nametrans as "INBOX". The user wants the new
"INBOX/cream" on remote. Hugh...  There are so many ways to do bad
things around.


For now, I disagree we should expose such complexity to the end-users
and let them potentially do so wrong things on their repository. Also,
end-users will have to _guess_ how the local folder name will be
returned by the server once created on remote.  IMAP servers may behave
in a random fashion, or at least not in a consistent way between each
others.

We _MUST_ ensure a 1-to-1 translation in any case. I know it is NOT
directly possible due to the way nametrans works (regexp). Then, I can
see two alternatives:

1. Ensure the 1-to-1 translation ourself by testing the rules against
both the remote and local foldernames (I mean, by really applying the
remote and local rules and carefully create the folders on both sides).
We must also be able to rollback if anything goes wrong.
This may asks to refactor the whole nametrans process in a library or
so.

2. Prohibit folder creation with nametrans and introduce a new simpler
option (ensuring 1-to1 mapping) to replace nametrans.

-- 
Nicolas Sebrecht