| Age | Commit message (Collapse) | Author |
|---|
|
This encapsulates what our multi-client IPC servers typically do on
startup:
1. Create a Core::LocalServer
2. Take over a listening socket file descriptor from SystemServer
3. Set up an accept handler for incoming connections
IPC::MultiServer does all this for you! All you have to do is provide
the relevant client connection type as a template argument.
|
|
This allows us to use TRY() or MUST() when calling it.
|
|
These ones all manage their storage internally, whereas the WebContent
and ImageDecoder ones require the caller to manage their lifetime. This
distinction is not obvious to the user without looking through the code,
so an API that makes this clearer would be nice.
|
|
Everyone used this hook in the same way: immediately accept() on the
socket and then do something with the newly accepted fd.
This patch simplifies the hook by having LocalServer do the accepting
automatically.
|
|
|
|
|
|
Applications that make use of LibConfig anyway have now a way of listing
the groups and keys without resorting to using Core::ConfigFile
directly.
|
|
This addresses the FIXME of detecting ConfigFile key removal.
|
|
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. :^)
|
