My presumption is that this needs to be written against the file service.

In the mustash world Chrome still maintains the loading and saving of preferences.

Other services, such as Ash, are accessing/modifying these values via a preference mojom.

Why do we believe that we need to move the pref loading/saving code to be a part of mus-ws?

As a foresight note: another team is working on the long task of pull all of the preference code out of chrome, into its own standalone service.

The display preference code takes in display::DisplayManager + display::DisplayConfigurator for the display state. For mustash, this state is located in the mus-ws process. That state is processed into JSON and then we have string preferences. The opposite happens for loading preferences, JSON is parsed and display state is set in DisplayManager + DisplayConfigurator.

If I understand how the preference service works correctly (which I might not then) it would happen something the following.

Loading:
(1) Chrome loads the display preference strings (from a file somewhere?)
(2) mus-ws gets preference strings from Chrome via IPC.
(3) mus-ws parses the JSON and sets display state.

Saving:
(1) mus-ws builds JSON from display state.
(2) mus-ws sends preference string to Chrome via IPC.
(3) Chrome saves the display preferences.

Ah so you were referring to how DisplayManager/DisplayConfigurator handle it.

Your understanding of how the preference service works is correct. Is this sufficient for mus-ws?