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

[Sebastian Spaeth]

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.

>   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?
 
> 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 :).

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. But none of this needs to prevent
this from going in now...

> 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 :))

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

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110905/b87aadc2/attachment-0001.sig>