Currently this method always succeeds, but that won't be true once we
switch to the Core::Stream API. :^)
Some of these places would ideally show an error message to the user,
since failure to save a file is significant, but let's not get
distracted right now.
I've attempted to handle the errors gracefully where it was clear how to
do so, and simple, but a lot of this was just adding
`release_value_but_fixme_should_propagate_errors()` in places.
This change unfortunately cannot be atomically made without a single
commit changing everything.
Most of the important changes are in LibIPC/Connection.cpp,
LibIPC/ServerConnection.cpp and LibCore/LocalServer.cpp.
The notable changes are:
- IPCCompiler now generates the decode and decode_message functions such
that they take a Core::Stream::LocalSocket instead of the socket fd.
- IPC::Decoder now uses the receive_fd method of LocalSocket instead of
doing system calls directly on the fd.
- IPC::ConnectionBase and related classes now use the Stream API
functions.
- IPC::ServerConnection no longer constructs the socket itself; instead,
a convenience macro, IPC_CLIENT_CONNECTION, is used in place of
C_OBJECT and will generate a static try_create factory function for
the ServerConnection subclass. The subclass is now responsible for
passing the socket constructed in this function to its
ServerConnection base; the socket is passed as the first argument to
the constructor (as a NonnullOwnPtr<Core::Stream::LocalServer>) before
any other arguments.
- The functionality regarding taking over sockets from SystemServer has
been moved to LibIPC/SystemServerTakeover.cpp. The Core::LocalSocket
implementation of this functionality hasn't been deleted due to my
intention of removing this class in the near future and to reduce
noise on this (already quite noisy) PR.
At the risk of introducing premature optimization, it only syncs to disk
5 seconds after the latest valid configuration update, to handle cases
where programs might send frequent updates that would go to disk every
time otherwise.
Also syncs to disk when the client connection closes.
Co-authored-by: Timothy Flynn <trflynn@pm.me>
We were only notifying clients about the change, but didn't actually
update the internal cache in ConfigServer itself.
Thanks to "The Grey One" for pointing this out. :^)
After opening a domain configuration and putting into our configuration
cache, we now monitor the underlying file for changes and send out
notifications to monitoring clients as needed.
This patch has three FIXME's:
- We create a new Core::FileWatcher for each domain.
- We don't yet detect removed keys.
- We don't know the type of key, so we assume everything is a string.
There are a number of ways we can solve those problems but let's not
hold up this patch while we wait for solutions. :^)
This patch adds a Config::Listener abstract class that anyone can
inherit from and receive notifications when configuration values change.
We don't yet monitor file system changes, so these only work for changes
made by ConfigServer itself.
In order to receive these notifications, clients must monitor the domain
by calling monitor_domain(). Only pledged domains can be monitored.
Note that the client initiating the change does not get notified.
This API lets applications specify which configuration domains they
will be accessing throughout their lifetime. It works similarly in
spirit to the kernel's pledge().
You cannot pledge_domains() more than once, and once you have used it,
it's no longer possible to access any other configuration domain.
This is obviously just a first cut of this mechanism, and we may need
to tweak it further as we go.
ConfigServer is an IPC service that provides access to application
configuration and settings. The idea is to replace all uses of
Core::ConfigFile with IPC requests to ConfigServer.
This first cut of the API is pretty similar to Core::ConfigFile.
The old:
auto config = Core::ConfigFile::open_for_app("App");
auto value = config->read_entry("Group", "Key");
The new:
auto value = Config::read_string("App", "Group", "Key");
ConfigServer uses the ~/.config directory as its backing store
and all the files remain human-editable. :^)
