[PATCH 2/3] Re: Maildir relative paths change was not complete

[Nicolas Sebrecht]

On Wed, Aug 17, 2011 at 04:08:26PM -0400, Ethan Glasser-Camp wrote:

> Hey, just wanted to mention that I also quietly started work on a 
> project called imapapi, which is basically a Python API for manipulating 
> maildirs, spawning a "rootless" Dovecot server, running tests against 
> it, etc.  I don't think Dovecot lets you disable individual features, 
> though, so I doubt it's as powerful as what you're working on (though I 
> haven't looked at it).  Anyhow I'm super busy all of a sudden so I 
> probably won't be able to work much more on it.
> 
> https://github.com/glasserc/imapapi

I just had a quick look at it.  Wow! This is impressive!

Here is my first thought:

There are some things asking to be definetly not mixed:

- We should start the tests from a (new) dedicated offlineimap
  repository (e.g. "offlineimap-test"). It has the test for offlineimap and
  rely on another tool (e.g. "imap-server-api")

- imap-server-api is the glue between offlineimap-test and the IMAP
  server. IOW, it provides a generic API for offlineimap-test using an
  IMAP server as backend.

- each IMAP server is a dedicated repository providing the IMAP server
  and the low-level commands to take control over itself.

Today, it seems that imapapi does not fully match this but I do think we
are on the good road. I think most of the above is currently mixed in a
single repository which is NOT a big deal as we could very easily split
it later. As an experimental stuff I think having off of this in one
repository is a good choice, for now.

I think it's so good because we have most of the above levels splitted
_by design_.

IMHO, the best good news here is that (due to the design) it's
amaizingly scalable:

- with a few changes, we can already say it will compatible with either
  dovecot, a fake IMAP server written in perl or any other IMAP server;

- others IMAP clients could easily write tests with it.


The only problem I could see is that it's not easily "hackable", maybe
as it's missing documentation (which is pretty normal at this stage).


Also, I think it's enough to start with and work together. Most
developers can help, the better it is. This is why I'm asking to work on
it, too.  At that time we could work in a dirty way (no release, no
maintainer, everything in one repository, perhaps merge the perl IMAP
server of Vladimir, etc). OfflineIMAP's mailing list is ours, let use
it. The only thing it's missing would be a license.


To conclude this mail I'd like to give a graphical view of the levels
I'm talking about at the beginning:

              +-----------+         +---+
(test suites) |OfflineIMAP|         |MUA|
              +-----------+         +---+
                 |                    |
                 |                    |
                 v                    v
               +-----------------------+
               |        commands       |
               +-----------------------+
                           |
                           |
                           v
   +---------------------------------------------------+
   |  imap-server-api            generic API           |
   | ------------------------------------------------- |
   |                                                   |
   | 1. compute the command or blindy relay to the     |
   |    lower level.                                   |
   |                                                   |
   | 2. check result by returned exit code (e.g. to    |
   |    ensure the low-level provides the command).    |
   |                                                   |
   | 3. relay anything needed from lower to upper.     |
   |                                                   |
   +---------------------------------------------------+
          |        ^                 |        ^
          |        |                 |        |
          |        |                 |        |
          v        |                 v        |
    +---------------------+    +---------------------+
    | low-level API       |    | low-level API       |
    | which has control   |    | which has control   |
    | over the IMAP server|    | over the IMAP server|
    |       A             |    |       B             |
    +---------------------+    +---------------------+

The imap-server-api is the key part, of course. It should do as much as
possible (as long as it's not changing from one IMAP server to another).

-- 
Nicolas Sebrecht