Instead of having one ring buffer per network, each network has one ring
buffer per entity (channel or nick). This allows history to be more
fair: if there's a lot of activity in a channel, it won't prune activity
in other channels.
We now track history sequence numbers per client and per network in
networkHistory. The overall list of offline clients is still tracked in
network.offlineClients.
When all clients have received history, the ring buffer can be released.
In the future, we should get rid of too-old offline clients to avoid
having to maintain history for them forever. We should also add a
per-user limit on the number of ring buffers.
On some IRC clients, NOTICE messages from a user which does not have a
user or host in its prefix (and therefore only have a Name, and look
like prefixes of servers), are treated as server notices rather than
user notices, and are treated differently. (For that matter, soju also
considers NOTICE messages from users with only a Name in their prefix as
special server messages). On most of these clients, NOTICE messages from
a user are formatted differently and stand out from the large flow of
incoming misceallenous server messages.
This fills the service user with fake User and Host values so that
NOTICE messages from it correctly appear as coming from a user. This
is particularly useful in the context of connection and disconnect
errors NOTICE messages that are broadcast from the service user to all
relevant downstreams.
This adds support for sending the exact error message of a network when
it is disconnected, in the reply to the service command `network
status`. This lets users easily examine why a network is currently
disconnected.
No lock is needed because all reads and writes of network.lastError are
made in the user goroutine.
Closes: https://todo.sr.ht/~emersion/soju/28
In order to notify the user when we are disconnected from a network
(either due to an error, or due a QUIT), and when we fail reconnecting,
this commit adds support for sending a short NOTICE message from the
service user to all relevant downstreams.
The last error is stored, and cleared on successful connection, to
ensure that the user is *not* flooded with identical connection error
messages, which can often happen when a server is down.
No lock is needed on lastError because it is only read and modified from
the user goroutine.
Closes: https://todo.sr.ht/~emersion/soju/27
Any SendMessage call after Close could potentially block forever if the
outgoing channel was filled up. Now the channel is drained before the
writer goroutine exits.
