Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
mutt
mutt
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 47
    • Issues 47
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 3
    • Merge Requests 3
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Mutt Project
  • muttmutt
  • Wiki
  • MailboxDriverCleanup

Last edited by Kevin McCarthy Dec 19, 2017
Page history

MailboxDriverCleanup

Motivation

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

Status

Most of the functionality is already modularized, but mx.c still contains implementations of specific functions which it shouldn't -- it should provide glue code mostly.

Implementation

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

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 incoming list themselves. The latter would be the case for IMAP, but also for a possible MAPI driver.

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

MAPI Support

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

The bigger issue would be profile handling as we can't seem to just pass auth and folder info via parameters to libmapi routines.

Clone repository
  • BeforeYouAsk
  • CheatSheets
  • CodingStyle
  • ConfigList
  • ConfigTricks
  • ConfigTricks
    • CheckAttach
  • DebugConfig
  • DebugTips
  • ExtendedMaildirFormat
  • FolderFormat
  • MacroSamples
  • MailConcept
  • MailConcept
    • Flow
    • Layout
  • MailboxDriverCleanup
View All Pages