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

[Nicolas Sebrecht]

On Mon, Sep 05, 2011 at 11:15:36AM +0200, Sebastian Spaeth wrote:
> On Sat, 3 Sep 2011 15:56:50 +0200, Nicolas Sebrecht <nicolas.s-dev at laposte.net> wrote:
> > 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.
> 
> I think there will be no way around 2-way nametrans (or
> forward_nametrans reverse_nametrans, or however you want to call them),
> nametrans rules are often unidirectional and there is no way to specify
> how a LOCAL folder should be names on REMOTE otherwise.
> 
> But I have explained in the mail on the previous patch, that we can
> safe-guard the user and make sure that back-and-forth translations
> actually end up with the same name to prevent misconfigurations.

Agree. I was wrong to talk about "two-ways nametrans" where I meant "One
nametrans applied on remote and another applied on local".

> >   cream (local) --become-> nice_cream (remote) --become-> ice_cream (local)
> >   --become-> nice_ice_cream (remote) --become-> etc...
> 
> Yep :) nice one
> 
> > I'm afraid this is a very _simple_ wrong usage.
> 
> Would the safe-guard patch (still to be created) make you less afraid of
> the feature?

Of course. In fact, I tend to be a bit stronger than that. I'm not
inclined to merge this topic without a safe-guard.

> > 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.
> 
> OfflineImap is like Unix, it gives you a long enough rope to hang
> yourself :).

Unix follows the KISS principle. We don't. But if we later realize we
_need_ such complex feature, I would be fine with a
"allow_complex_nametrans" or "disable_nametrans_safe_guard". ,-p

> Let's a) implement --info which shows how folders are translated, let's
> also b) ensure that back-and-forth nametrans rules actually end up with
> the same name, and c) let's implement --dry-run to give a user a chance
> to inspect what would be happening.

Wonderfull plan!

> > 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.
> 
> The 1-to-1 translation is dead-easy and I will implement it in the
> folder-synchronization code. As for rollback, that is no task that I
> want to address in the near term (we'd be better off using a proper
> database with rollback for that :))

Honestly, I'm not sure we need any database changes for the purpose.

> > 2. Prohibit folder creation with nametrans and introduce a new simpler
> > option (ensuring 1-to1 mapping) to replace nametrans.
> 
> Possible too, but way less powerful obviously.

-- 
Nicolas Sebrecht