No option to add welcome motd message as parameter
donpui opened this issue · 8 comments
There is no option to add welcome motd message via parameter providing message or setting file to load as message.
Currently only option is to edit server.py file and include message in it
IMO the welcome message should not be a configuration option, but modifiable at runtime. This is needed for example to warn users beforehand of server maintenance downtime, or of high load (e.g. ongoing attacks). Having the server restart every time just to change the message is not ideal.
Modifiable at runtime file would be good option. However it need to detect changes and update message stored in memory, not just read file with every connection to provide newest message.
What's wrong with re-starting the server (to change MotD)? (Clients should just immediately re-connect and all is well).
I don't think any client except Python actually implements this feature.
No other clients will re-connect? (Note they don't need to journal state to disk like the mailbox does to have the feature)
The rust client definitely won't. For the Go client I'm not sure, but I had a quick look at the code and did a few greps for keywords that I'd expect to come up in that context ("reconnect", "timeout", "retry", …) and could not find any signs of such an implementation either.
The rust client used to re-connect IIRC ... why doesn't it any more?
In any case, the general "philosophy" of the code if you will is to be resilient in the face of network instability. Certainly one reason a connection could go away is if the server is re-started, but there are many other reasons. The reference implementation, state-machines and spec should, I believe, make it clear that correct behavior is to re-connect to the mailbox.
Certainly for Dilation to work, clients must know how to re-connect to their mailbox whenever a network connection goes away. So clients that don't already re-connect should be taught how to.
Since everything else in the server is built around having state properly serialized (before network messages go out) special-casing a "live" reload of just this one piece of state is out-of-place. (This is inspired by the "Waterken" server, that is an old project generally in the "capability theory" space).
The rust client used to re-connect IIRC ... why doesn't it any more?
The Rust code base has undergone some heavy refactoring, and some parts have been rewritten from scratch multiple times. Since then, it has never been a high enough priority for me to work on the reconnect logic again.