Implement the backend synchronizer

[soywod]

A cache/offline system is needed for most of the frontends (refs https://github.com/soywod/himalaya/pull/155#issuecomment-1060363876 https://github.com/soywod/himalaya/issues/156). I propose to implement a lib (and maybe export it in the future to compete with mbsync and offlineimap) that synchronizes emails between an IMAP server and a local Maildir. Then we need to introduce special backends (IMAP offline and POP offline) that use internally a Maildir backend (a bit like the Notmuch backend).

[toastal]

How is this different than running mbsync?

[soywod]

From my comment:

To have the best UX (in my opinion), a TUI should work offline (a bit like a GUI, think Thunderbird), and it should work out of the box (or with toggle feature). This last statement is not compatible with asking users to install and configure on their own mbsync or offlineimap. And none of them propose a lib.

I would like to make Himalaya usable by default. A TUI plugged to an IMAP server is not usable by default (too much delay), and I don't want to ask people to install their own tool (ref mbsync/offlineimap). It is this same argument that motivated me to support the Maildir format natively, instead of asking people to install and configure dovecot.

Another alternative could be to make Himalaya configure mbsync or offlineimap by creating the right config file. But this solution still requires the user to install the tool on their own.

Any proposition?

[toastal]

I'm slightly in favor of using existing tools and pointing to their docs rather than reinventing and forking that wheel unless there's a good reason. That said, if I were pointing to a tool, I would endorse and "support" just one so it doesn't become a hassle having forks in the documentation.

But maybe its not too much work and 'owning' that code is good or maybe there's room to innovate.

[soywod]

I'm a bit suspicious about forking, as you said it can become a hassle very quickly. I was more thinking about relying on some binaries, but this requires either to include them with the project (kind of fork in fact) or to ask users to install them manually.

There is also another problem: cross compatibility. Himalaya is compatible on linux, mac and windows, but I'm not sure about mbsync.

But maybe its not too much work and 'owning' that code is good

I think (but I may be wrong) that email sync is not a big deal. The only mutable parts are flags, the rest does not change. It can be resumed by adding/removing emails, updating flags and maintaining an ids hashmap.

maybe there's room to innovate

This argument is the one that motivated me to start himalaya, I kind of hope the same for a synchronizer (because there is a real need here: there is no solid solution to synchronize emails that is cross-platform compatible and that can be used as CLI and library).

[stpr-dev]

My 2 cents: I am actually in favour of a new backend as mbsync isn't cross-platform which has been a headache for me personally as I have Windows specific workflows. Also, asking people to configure mbsync separately and then switch back to this application isn't good UX wise. The added bonus, a CLI provides a solid alternative to mbsync, which in this case has real usecases, particularly for cross-platform usage.

[soywod]

I am actually in favour of a new backend as mbsync isn't cross-platform which has been a headache for me personally as I have Windows specific workflows. Also, asking people to configure mbsync separately and then switch back to this application isn't good UX wise. The added bonus, a CLI provides a solid alternative to mbsync, which in this case has real usecases, particularly for cross-platform usage.

I share the exact same vision as yours. I am convinced about the real need. I am also convinced about the same needs for contacts (CardDAV) and events (CalDAV). I just need more free time and/or financial help to go forward. Thanks for your support!