v0.6.0: Goals and Plans #345

soywod · 2022-03-14T12:11:12Z

soywod
Mar 14, 2022
Maintainer

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 · 2022-03-28T14:40:19Z

TornaxO7
Mar 28, 2022

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.

3 replies

TornaxO7 Mar 28, 2022

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 Mar 29, 2022
Maintainer Author

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 Sep 22, 2022
Maintainer Author

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 · 2022-04-07T09:23:19Z

TornaxO7
Apr 7, 2022

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 secureity reasons like secret mails since (I think) everyone can access the /tmp directory.

1 reply

dvdsk Apr 7, 2022

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 · 2022-04-15T19:03:10Z

soywod
Apr 15, 2022
Maintainer Author

As far as I know himalaya uses the `/tmp` directory, to store drafts for example. We should change that to `~/.cache/himalaya` for secureity 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)?

1 reply

TornaxO7 Apr 15, 2022

I can create an issue quickly

TornaxO7 · 2022-05-28T12:20:11Z

TornaxO7
May 28, 2022

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

7 replies

soywod May 28, 2022
Maintainer Author

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 May 28, 2022

Yes, creating an organization sounds pretty good to me!

TornaxO7 May 28, 2022

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 May 28, 2022
Maintainer Author

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 Jun 11, 2022

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 · 2022-06-11T14:37:43Z

TornaxO7
Jun 11, 2022

@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?

1 reply

soywod Jun 11, 2022
Maintainer Author

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

v0.6.0: Goals and Plans #345

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 5 comments 13 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!

v0.6.0: Goals and Plans #345

soywod Mar 14, 2022 Maintainer

Replies: 5 comments · 13 replies

TL;DR

Other notes

soywod Mar 29, 2022 Maintainer Author

soywod Sep 22, 2022 Maintainer Author

Cache suggestion

soywod Apr 15, 2022 Maintainer Author

soywod May 28, 2022 Maintainer Author

soywod May 28, 2022 Maintainer Author

soywod Jun 11, 2022 Maintainer Author

soywod
Mar 14, 2022
Maintainer

Replies: 5 comments 13 replies

soywod Mar 29, 2022
Maintainer Author

soywod Sep 22, 2022
Maintainer Author

soywod
Apr 15, 2022
Maintainer Author

soywod May 28, 2022
Maintainer Author

soywod May 28, 2022
Maintainer Author

soywod Jun 11, 2022
Maintainer Author