Configuration boilerplate

Sebastian Spaeth Sebastian at
Fri Aug 26 14:47:48 BST 2011

On Thu, 25 Aug 2011 07:17:12 -0800, Dave Abrahams <dave at> wrote:
> Scenario: it takes hours to sync "All Mail."  INBOX syncs in seconds,
> but I want to continue to receive mail in my INBOX while "All Mail" is
> syncing.  Even if syncing starts with INBOX, it gets "stuck" doing hours
> of work on "All Mail" and I can't read anything in INBOX in the
> meantime.

I see. Yes that would be difficult to achieve. With the new per-account
locking system you could workaround this with different accounts like
you do now and simply leave another offlineimap running in background
syncing "All Mail"...
> > Sure, but this would require that something global keeps tab of all used
> > maildir folders across accounts. 
> Huh?  Just have a step at startup that validates the config file, neh?

Some examples:
Account 1: IMAP1 <-> Maildir1
Account 2: IMAP2 <-> Maildir2

 root = /home/u/mail

 root = /home/u/mail/Personal

What should we do? Abort because if you have a folder Personal/Favorites
on your IMAP1 you'll share a Maildir folder, but not if you don't have a
"Personal" folder on IMAP1?

Account 1: IMAP1 <-> Maildir1 (root = /home/u/mail)
Account 2: IMAP2 <-> Maildir2 (root = /home/u/mail)

 folderfilter = lambda foldername: foldername not in ['Spam']

 folderfilter = lambda foldername: foldername in ['[Gmail]/All Mail']
 nametrans = lambda folder: 'IMAP2.' + folder

(Recognize that setup? its similar to yours) What should we do? Abort
because *if* you have a folder IMAP2 on your IMAP1 you'll
share a Maildir folder, etc. With folderfilters and nametrans, it is
non-trivial to detect in which cases we will be sharing a maildir. The
best we could do is to detect whether a maildir root lies within another
maildir root. But that would prevent e.g. your careful setup from

Happy to accept solutions for sane validation mechanisms.

> > The way OfflineImap is designed has Accounts be totally different
> > operations that know nothing of each other, and even folders are
> > pretty much separated (which is one of the reasons why it would be
> > hard to detect moves of mails between folders).
> I don't see the problem here, sorry.

A Folder() object has no knowledge about mails in other Folder()
objects, in fact they usually don't have the lists of containing mails
loaded at the same time, so detecting a move from FolderA to FOlderB is
non-trivial with the current architecture.

Same with Accounts and as I have shown, without knowing which folders
exist on the servers, it is not possible to detect if there will
actually be sharing of maildirs.

> > I would try to see it positive, I find the configuration much shorter
> > than a proper muttrc :). If you know of any ways that would make life
> > easier for you, let us know and I'll put it on my list.
> I thought you'd never ask ;-)
> My first thought was to give me (documented) programmatic access to the
> configuration so I can write Python code that builds whole sections of
> the config file.  However, it occurs to me that a one syntactic
> extension could reduce my config considerably.  I've rewritten it below
> using an "inherit =" clause for each remote repository.

inherit sounds like a good solution to me and should be possible to
implement somehow.

On top of the core functionality, SafeConfigParser supports interpolation. This means values can contain format strings which refer to other values in the same section, or values in a special DEFAULT section. Additional defaults can be provided on initialization.

Another thing that would be possible is to use the standard
interpolation feature that the SafeConfigParser in Python offers. This
means values can contain format strings which refer to other values in
the same section, or values in a special DEFAULT section. For example:

[Repo G1]
nametrans = %(googlenametrans)s

[Repo G2]
nametrans = %(googlenametrans)s

googlenametrans = lambda folder: '.' if folder == 'INBOX' else '.' + folder

So you could at least set common variables only once for all the
accounts (although you would still need the boilerplate). This would be
a single line of code change in OfflineImap.

I've noted the 'inherited' idea down, I like it a lot.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <>

More information about the OfflineIMAP-project mailing list