v0.6.0: Goals and Plans

[soywod]

Before the v0.5, Himalaya was only able to connect to IMAP servers.
Starting from the v0.5, I introduced the concept of backends which allows Himalaya to connect to other sources like Maildir and Notmuch.

From the v0.6, I would like to bring Himalaya to the next (final) step: gather all the logic into a lib, and make the CLI a simple frontend like another. The aim is really to turn Himalaya into an email API for UIs/frontends/clients to consume it.

Sources: https://excalidraw.com/#json=wYvjR8B8vWcUrlcgICF9j,OvTnLeQO0tU_-X39qvuVSQ

Some enhancements and changes are needed in order to achieve this goal:

• Make Himalaya use the cargo workspace feature in order to separate the lib for the CLI module. See Separate the CLI from the lib module #340.
• Himalaya should work offline (most of the frontends need it for an optimal user experience). This requires to implement an IMAP to Maildir synchronizer. See Implement the backend synchronizer #342.
• A composer should be implemented for frontends to be able to produce valid MIME messages. See Implement the composer module #341.
• The global config needs to be refactored in order to make it more intuitive and structured. Since the beginning, options have been added on the fly and most of them are misplaced. This will lead to breaking changes, but I prefer to do them now rather than after the v1.0.0. See Refactor the config file to make it more intuitive and structured #344.

[TornaxO7]

Is it possible to create some structs in your backend block?
Because your functions like acc_select, acc_select_by_name_or_default always
start with the acc prefix. So something like Account::select(Query query)
might be suitable. Your Backend block shows in a nice way, that some functions
are related to the Account, Mbox and Msg structs so why not changing them
to static (or how it's called if you create a function without the &self
parameter) functions?

TL;DR

I could imagine the following for example:

pub struct Account {
    // the stuff ...
}

impl Account {
    pub fn select(Query query) -> Accounts {
        // ...
    }

    pub fn select_by_name_or_default(String string) -> Account {
        // ...
    }

    // and so forth..
}

So we can use it like this:

let accounts = Account::select(Query query);

Other notes

We would have probably some naming conflicts, but I think that this isn't such a
big problem.

[TornaxO7]

A pub trait Backend could be also probably neat. Because we have:

• acc_select <=> mbox_select <=> msg_select
• acc_insert <=> mbox_insert <=> msg_insert

etc.

So creating something like impl Backend for AccountBackend or something like
could help to organize the code probably? (It's just a suggestion)

[soywod]

I like this idea for the fact that the backend impl for accounts will be defined in the account folder/scope rather than in the backend scope.

[soywod]

I decided not to implement this just for the fact that there is no reason for them to be split (except for the fact that they belong to their domain). You will never have a ImapMboxBackend with a MalidirMsgBackend, they are always all together. I also removed the account part of the backend, in practice it was useless. Thanks anyway for the suggestions, it helped me finding the right implementation!

[TornaxO7]

Cache suggestion

As far as I know himalaya uses the /tmp directory, to store drafts for example. We should change that to ~/.cache/himalaya for security reasons like secret mails since (I think) everyone can access the /tmp directory.

[dvdsk]

I agree /tmp might not be the best place. Are drafts always stored on the mail server? If not cache would be a bad place since it implies the files can be removed without loss.

Maybe the XDG_DATA_HOME/himalaya/drafts is a good alternative?

[soywod]

As far as I know himalaya uses the `/tmp` directory, to store drafts for example. We should change that to `~/.cache/himalaya` for security reasons like secret mails since (I think) everyone can access the `/tmp` directory.

I think it is a very good suggestion! Maybe open an issue (not to forget it)?

[TornaxO7]

I can create an issue quickly

[TornaxO7]

Just to be sure if I understand you correctly: Himalaya is going to become a backend-emal-library, right?

[soywod]

Totally, default UIs are just "bonus". That's why the TUI and GUI are not a priority at all. The Vim plugin and the CLI are a bit different (kind of advanced compare to the rest) because of Himalaya's historical background. Himalaya used to be a simple Vim plugin, then a CLI used by the Vim plugin.

I also have an alternative in mind: instead of having by default all those UIs, we could create a GitHub organization and split UIs into dedicated repos. It's a bit stupid because it used to be the case. But I did not expect this project to grow that fast and the goal to change so much (going from a Vim plugin to a Rust lib 🤣). This way the Himalaya organization could propose default UIs in their dedicated repos (sth like himalaya-org/himalaya-lib, himalaya-org/himalaya-cli, himalaya-org/himalaya-vim etc.)

[TornaxO7]

Yes, creating an organization sounds pretty good to me!

[TornaxO7]

I'd also say, that instead of writing an extra UI for the vim-plugin we could also use the TUI in vim for the "UI"-himalaya-vim-plugin

[soywod]

I'm not sure to understand your last point. You mean to use Vim and the plugin in place of a TUI? I'm afraid this sounds overkill, but needs to be thought well!

[TornaxO7]

You mean to use Vim and the plugin in place of a TUI?

no no, I mean that we could embed the TUI in vim since vim and neovim have the :terminal command. So we're just calling the TUI in vim and neovim`. Or we are really writing a good plugin. But this can be thought in the future.

[TornaxO7]

@soywod is it possible to create an organisation? I'd like to have something like a RFC-Repository for example (also UML diagrams could be useful here) for himalaya where we can list what himalaya (the lib) should be able to do or should I rather just put them into a directory?

[soywod]

Yeah, I would like to finish the lib extraction before. I let you know!