259f7323d4d5867b45ba3c9383650a4c4a6cd486 — Simon Ser 2 months ago 1cd0951
Add status update 51
1 files changed, 57 insertions(+), 0 deletions(-)

A content/blog/2023-03-20-status-update-51.md
A content/blog/2023-03-20-status-update-51.md => content/blog/2023-03-20-status-update-51.md +57 -0
@@ 0,0 1,57 @@
date = "2023-03-20T00:00:00+02:00"
title = "Status update, March 2023"
slug = "status-update-51"
lang = "en"
tags = ["status update"]

Hi all!

In the past week or so I've focused on a <abbr title="New Project of the
Month">NPotM</abbr>: [go-imap], an IMAP library for Go. "But Simon, a New
Project of the Month is supposed to be _new_!" Right, right, the NPotM is a
lie… But only a half-lie: I'm rewriting it from scratch. go-imap was one of the
first Go projects I've written, and I couldn't recite the IMAP4rev1 RFC by
heart at the time. This is just a roundabout way to say that mistakes were
made. IMAP extensions — a lot of which provide important functionality — were
designed to be implemented out-of-tree in separate Go modules. However many
extensions change the behavior of existing commands, so trying to design a
modular system is a fool's errand which only results in a more complicated API.
Go channels were (ab)overused in the public API. The internals were not
designed with goroutine safety in mind, so races were ducktaped after the fact.
It's not possible to run multiple IMAP commands concurrently: each time
a command is sent, the caller gets to twiddle their thumbs until the reply
comes back before sending a new one, paying the full price of the roundtrip.
The parser has a weird intermediate representation based on `interface{}` Go
values. Many functions and types are exported in the public API but really
shouldn't be.

For all of these reasons, I've decided to start from scratch rather than trying
to incrementally improve the library. This turned out to be a good decision: in
one week, I had a working client which has less bugs and more features than
go-imap v1. I based my work on the newer IMAP4rev2 RFC, which provides a better
base feature set than IMAP4rev1. I've ported [alps] to the new API to make sure
I didn't miss anything. I still need to write the server part and tests.

In IRC news, the [soju] database message store submitted by delthas has finally
been merged. Now, the message history can be stored in the database rather than
in plain-text files. This enables features such as full-text search and
retaining IRCv3 message tags. The [goguma] mobile client now has a gallery view
for images, supports replies via the [`reply` client tag] (in a non-intrusive
fashion), and scrolls to the unread indicator when a conversation is opened.

As usual, I worked on many other smaller tasks in other projects. The wlroots
[output layers] have been merged, but are still opt-in and require compositor
support. lists.sr.ht now uses [go-emailthreads] to display replies in the patch
view. `hut pages publish` can now take a directory as input, and will generate
the tarball on-the-fly. There are many other tiny improvements I could mention,
but it'd get boring, let's wrap up this status update. See you next month!

[go-imap]: https://github.com/emersion/go-imap/tree/v2
[alps]: https://sr.ht/~migadu/alps/
[soju]: https://soju.im
[goguma]: https://sr.ht/~emersion/goguma/
[`reply` client tag]: https://ircv3.net/specs/client-tags/reply
[output layers]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3640
[go-emailthreads]: https://git.sr.ht/~emersion/go-emailthreads