Before, the information needed to display different parts of the UI was
tightly coupled to the specific messages being sent back and forth to
the backend worker. Separating out a models package allows us to be more
specific about exactly what a backend is able to and required to
provide for the UI.
Adds an archive command that moves the current message into the folder
specified in the account config entry.
Supports three layouts at this point:
- flat: puts all messages next to each other
- year: creates a folder per year
- month: same as above, plus folders per month
This also adds a "-p" argument to "cp" and "mv" that works like
"--parents" on mkdir(1). We use this to auto-create the directories
for the archive layout.
If a MailboxInfo has the attribute \Noselect,
it is not possible to use this name as a selectable mailbox.
Therefore it should not be passed to the directory handlers.
The issue pops up if one has a hierarchy like this:
INBOX
INBOX/lists/stuff
INBOX/lists/otherStuff
Even though lists is not a valid inbox (doesn't contain mail, only other maildirs)
it will show up in the directory listing, when we iterate over the MailboxInfo.
It does have the corresponding attribute set though and we can simply filter it out.
Worker.callbacks contains two types of callbacks: some are action callbacks,
some are message callbacks. Each of those is access from one side of the
communication channel (UI goroutine vs. worker goroutine).
Instead of using a channel, we can use two different maps for each kind. This
simplifies the code and also ensures we don't call an action callback instead
of a message callback (or the other way around).
Message IDs are allocated for both messages from UI to workers and the other
way around. Hence, the global nextId variable is accessed from multiple
goroutines.
Instead, use atomic to access the global counter.
Unfortunately, the IMAP protocol hasn't been designed to be used from multiple
goroutines at the same time. For instance, if you fetch twice the same message
from two different goroutines, it's not possible to tell whether the response
is for one receiver or the other. For this reason, go-imap clients aren't safe
to use from multiple goroutines.
This commit changes the IMAP workers to be synchronous again (a command is
executed only after the previous one has completed). To use IMAP from different
threads, popular clients (e.g. Thunderbird) typically open multiple
connections.
Worker.Process* functions were called in different goroutines than
Worker.Post*. Protect the map with a mutex. Also make the map unexported to
prevent external unprotected accesses.
Worker.Process* functions used to delete items from the map. However they
didn't delete the element they retrieved: callbacks[msg.InResponseTo()] was
read while callbacks[msg] was deleted. I'm not sure I understand why. I tried
to delete the element that was accessed - but this broke everything (UI froze
at "Connecting..."). I don't believe any elements were actually removed from
the map, so the new code just doesn't remove anything.
Ben Burwell
Drew DeVault
Reto Brunner
Robert Günzler
Yash Srivastav
Simon Ser
Markus Ongyerth