State
Caveats
Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.
If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right.
No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.
Contents
Overview
“State” refers to the persistent storage of data that lies outside of configuration and does not directly represent a user’s work. Examples of state include the jump lists in Windows, recent file lists and so forth. Cached data and offline-accessible material would however be handled by the Cache Manager.
The Windows Registry is effectively a random heap of state and configuration. Layer Config was intended to only store configuration, not state. Whether it would nonetheless be considered pragmatic to store state in Layer Config remains to be determined. Should this be the case, state and configuration would be clearly separated.
Implementations of state have a habit of being painfully intractable. Jump lists in Windows are stored as files under %APPDATA%\Roaming\Microsoft\Windows\Recent\AutomaticDestinations in some inscrutable format. For example, IrfanView’s jump list is held in a file called “70d9ada92108d731.automaticDestinations-ms”, which anyone can of course immediately discern with no effort. There is no method to clear the jump list for a single application; identifying and deleting the respective “automaticDestinations-ms” file to clear the list also has the unwanted side-effect of erasing any pinned items. Jump list entries for files that no longer exist remain seemingly forever. There is no way to disable the jump list for individual programs where it is of no use and adds unwanted clutter to the application’s context menu.
In part this is simply a matter of poor implementation (no clean-up of outdated file references) and poor UI (no manual clearing and limited control). Even so, per accountability principle, having hidden and unmanageable state is intolerable.
Another common example is windows that open off-screen as the saved window position is no longer valid for the desktop co-ordinates. This should not be of concern here as the window manager will automatically reposition windows shown with invalid co-ordinates unless deliberately overridden.
Session state
Session state refers to an application’s set of open documents and their window positions. There should be a standard mechanism for storing and retrieving this data. This can be used when signing out with open applications, or when upgrading and restarting an application, to allow the user’s working environment to be retained. This could even be extended to a crash-resistant behaviour as found with Web browsers.
For some people, the set of open documents represents a static space and a working memory, i.e. they offload the cognitive task of remebering what they are working on to the computer. Losing this state upon a restart causes an effective loss of working memory.
While some software (e.g. Microsoft Office, Windows File Explorer, and most browsers) already has this facility, it is not universal outside of the modern Mac.