[gnome-session.wiki] Update Session Saving Brain Dump

[Ray Strode <halfline src gnome org>]

commit 0f197ff5c539e6d0f2fbd30ddc60ad04780b1a54
Author: Ray Strode <halfline gmail com>
Date:   Mon Jan 17 17:32:21 2022 +0000

    Update Session Saving Brain Dump

 Session-Saving-Brain-Dump.md | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/Session-Saving-Brain-Dump.md b/Session-Saving-Brain-Dump.md
index ca2f95b..c1e3dc8 100644
--- a/Session-Saving-Brain-Dump.md
+++ b/Session-Saving-Brain-Dump.md
@@ -13,6 +13,11 @@ Broadly speaking, there are two main parts to application session handling: Ensu
 - There's not yet a general API for requesting an application gets started when the starts.  There's a 
request for [adding one to GLib] (https://gitlab.gnome.org/GNOME/glib/-/issues/2445)  though the API is yet 
to be determined. We should figure that out and probably make it use the xdg-portal api transparently under 
the hood for flatpaks.
 
 ## Application Saving
-- There are some aspects of session saving the application can't directly control. For instance, the 
workspace an application is started on or its global position.  Applications will need some way to request 
mutter opaquely track that information on a surface by surface basis, and then upon app start up the 
application could request that mutter put specific surfaces "back the way they were before".  Samsung has one 
proposal for such [a protocol] 
(https://lists.freedesktop.org/archives/wayland-devel/2018-February/037236.html).
+- There are some aspects of session saving the application can't directly control. For instance, the 
workspace an application is started on or its global position.  Applications will need some way to request 
mutter opaquely track that information on a surface by surface basis, and then upon app start up the 
application could request that mutter put specific toplevel surfaces "back the way they were before".  
Samsung has one proposal for such [a protocol] 
(https://lists.freedesktop.org/archives/wayland-devel/2018-February/037236.html).
+
+- Other bits of state, such as app widget state need to be saved and restored as well. There's a GTK 
proposal for doing that [here](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3624)
+  - That proposal leaves it up to the application to figure out where the state gets written out to.
+  - There's some concern that having all applications handle this on their own could lead to the "thundering 
herd" problem where many different applications are all saving at the same time.
+  - There's also the reality that the bits of application state that mutter should track (like workspace 
etc) need to be stored separately from the rest of the application state.
+  - There's a proposal to consolidate state saving behind an api provided by gnome-session 
[here](https://gitlab.gnome.org/pwithnall/gnome-session/-/commits/session-restore). It provides a new 
`RegisterRestartData` method where the application tells the session manager about a GtkApplication bus 
object that has `RestartData` GVariant property on it. The GVariant gets synched to a gvdb managed by 
gnome-session.
 
-- Other bits of state, such as app widget state need to be saved and restored as well. There's a GTK 
proposal for doing that [here]()