smproxy and gnome-smproxy break the XSMP

[Olivier Chapuis]

Hello,

Both smproxy and gnome-smproxy has a bug. I will describe this
bug and propose solutions.

First I recall one paragraph of the X session manager protocol
(XSMP) specification:

  "Some clients may wish to manage  the  programs  they  start.
  For  example,  a  mail program could start a text editor for
  editing the text of a mail message.  A client that does this
  is a session manager itself; it should supply the clients it
  starts with the appropriate  connection  information  (i.e.,
  the  SESSION_MANAGER  environment variable) that specifies a
  connection to itself instead of to  the  top  level  session
  manager." [end of section 3]

So a "simple client" can be a session manager (sm for short) for a set
of clients it starts itself. As the SESSION_MANAGER env variable is
set to point on the "simple client", the top level sm does not manage
the clients which are XSMP compliant (because they connect to the
simple sm).  Now if one of these clients uses the old session manager
protocol (based on the WM_COMMAND, WM_SAVE_YOUR_SELF, ...etc
properties, see the appendix C of the ICCCM2) and if either smproxy or
gnome-smproxy run, then the top level sm will manage this client. More
exactly want can happen is a competition between the simple and the
top level sm (via sm proxies, if the simple sm has a proxy) for
managing the client.  That's the bug.

The reason is clear. When a top level window is mapped the sm proxies
should compute the value of the SESSION_MANAGER ev on the application
which maps the window and should ignore this window if this value is
not equal to the proxy SESSION_MANAGER ev (or should connect the
correct sm).

Both smproxy and gnome-smproxy do not do that ... a good reason
is that it is _not_ possible to do that (in general).

I see two solutions:

1. Remove smproxy from XFree and gnome-smproxy from GNOME with
the hope that all alive applications which use the old sm protocol
will switch to the new one. Probably a bad solution ...? By the
way it seems that KDE does not have and do not run by default a
sm proxy.

2. Add a simple protocol between sm proxies and sm by using a property
SESSION_MANAGER(STRING) which can be set by a sm (top level or not)
on a leader window:

  A session manager can set on a leader window (which use the old
  session manager protocol) a property SESSION_MANAGER(STRING) set
  to the value of its network address (i.e., the value of "its"
  SESSION_MANAGER environment variable). A sm proxy should use this
  property to contact the correct sm or to ignore this window if it
  works for only one sm (e.g., the top level one) and the value of
  this property is not the network address of its session manager.
  The proxy should monitor the SESSION_MANAGER property and update
  the sm connection(s) accordingly (typically a window will map
  without the SESSION_MANAGER property set, if SM_CLIENT_ID is not
  set a concerned sm can then set the SESSION_MANAGER property).
  [We can do a more safe stuff: add a SESSION_MANGER_CHECK_WINDOW(Window)
  property that should be also set by the sm on the top level window
  and gives the id of a window which belongs to the sm and have the
  property SESSION_MANGER_CHECK(STRING) set to the value of the
  SESSION_MANAGER property. This can be used by a sm to answer the
  question: does an other alive sm already set the SESSION_MANAGER
  property?]

It will be simple to modify smproxy and gnome-smproxy to avoid the bug
by using this protocol (just monitor the SESSION_MANAGER property and
if it is not equal to the value of the SESSION_MANAGER ev variable of
the proxy, ignore the window). I can provide a patch for smproxy
(which will be easy to apply to gnome-smproxy).  In the future, if
needed, one can imagine a sm proxy which works for all the running
(master and simple) sm.

I am not an XFree developer neither a GNOME developer. If the
maintainers of smproxy and gnome-smproxy can be agree on a method to
solve the described bug (as the solution proposed or any others), then
the first step will be to modify smproxy and gnome-smproxy (I am ready
to provide patches). The second step is to document the solution (Of
course the sources code can be considered as a good documentation). I
suggest that this should not be discussed now as this is useless if
both smproxy and gnome-smproxy maintainers do not want to fix the
described bug.

Regards, Olivier