Direction comments

[Jared Rhine <jared@xxxxxxxxxxx>]

Some comments on my perspective on the direction of offlineimap.
These are phrased in "command form" language, but of course they are
only suggestions, each of which is fraught with peril.

1. Stick with python.  Switching to another language might very well
   break momentum and would certainly reduce my confidence until the
   new codebase has matured again.  Switching languages would just be
   showing off :)

2. Switch to a multi-process model using IPC.  Ala postfix or qmail.
   These are rock-solid architectures.  I forget exactly how qmail
   works; postfix using a simple socket protocol for IPC.  This would
   be a considerable shift in architecture and I don't discount the
   difficulty of doing so.  But you could stop futzing with threading
   at least.  And the internal architecture would probably be cleaned
   up.

3. Break the GUI out of the main codebase.  The GUI is not (or should
   not be) core to the functioning of the application.  And I bet
   fewer people use it (them!) than you might think.

4. Lower expectations of additional coding help.  Open source is
   "personal requirement" driven; I have no desire to contribute to
   offlineimap because it works perfectly for me.  There would have to
   be missing features or bugs for me to want to jump in.  (You might
   be able to encourage contributions if you actually remove the GUI
   support entirely; _then_ someone would have a feature (a GUI) that
   they'd like to see improved.)

5. Go ahead and dive into a rewritten IMAP library; it's clear you
   kind of want to :)  And the python community will thank you, sounds
   like.

-- jared@xxxxxxxxxxx

"Better to be of a rare breed than a long line." -- TDK