Changes between Version 1 and Version 2 of MailboxDriverCleanup


Ignore:
Timestamp:
Oct 21, 2013 7:38:53 PM (4 years ago)
Author:
MichaelRay
Comment:

typo. 'modularized' = (made) modular

Legend:

Unmodified
Added
Removed
Modified
  • MailboxDriverCleanup

    v1 v2  
    11=== Motivation ===
    22
    3 The mailbox drivers should be better separated into modules than is the case now to allow for easier addition of new storage backends (and, of course, to have fewer `switch` statements and `#ifdef` orgies.)
     3The mailbox drivers should be better separated into modules than is the case now to allow for easier addition of new storage back ends (and, of course, to have fewer `switch` statements and `#ifdef` orgies.)
    44
    55=== Status ===
     
    1111As a first step, the code in mx.c implementing mailbox-driver-specific code should be moved to mh.c/mbox.c/imap. This should also count for the mbox-related stuff in buffy.c for `$check_mbox_size`.
    1212
    13 This probably means to add some new functions like `mx_has_newmail()` or whatever to modularize mailbox polling. For polling, we also maybe want to distinguish between drivers that work on single mailboxes and those that work on groups and walk the incomming list themselves. The latter would be the case for IMAP, but also for a possible MAPI driver.
     13This probably means to add some new functions like `mx_has_newmail()` or whatever to modularize mailbox polling. For polling, we also maybe want to distinguish between drivers that work on single mailboxes and those that work on groups and walk the incoming list themselves. The latter would be the case for IMAP, but also for a possible MAPI driver.
    1414
    1515We also want a registry for drivers, i.e. a simple array of a driver struct where `ctx->magic` is an index into. Adding the driver struct pointer to CONTEXT at mailbox open time (instead of `ctx->magic`) would be possible too, though we nowhere use such an OOP-like design.
     
    1717=== MAPI Support ===
    1818
    19 The [http://www.openchange.org/ OpenChange] project provides a `libmapi` for accessing MS exchange servers using native protocolls. Such a driver doesn't seem to be too hard to implement, it should be even easier once the mx drivers are modularized better.
     19The [http://www.openchange.org/ OpenChange] project provides a `libmapi` for accessing MS exchange servers using native protocolls. Such a driver doesn't seem to be too hard to implement, it should be even easier once the mx drivers are more modular.
    2020
    2121The bigger issue would be profile handling as we can't seem to just pass auth and folder info via parameters to libmapi routines.