Wayland hot-replace server?

[Sam Spilsbury]

On Mon, Mar 7, 2011 at 3:41 AM, Bill Spitzak <spitzak at gmail.com> wrote:
> I think the original poster's idea is exactly what is needed:
>
> I the compositor crashes or exits, the clients will detect this. It is then
> the client's job to find a new compositor and recreate their state on the
> new one. Most toolkits store quite enough redundant information that they
> should be able to do this, I would suspect the biggest trick will be to
> completely forget any ids from the previous compositor.

Indeed - we also need to make a difference here between the session
going down and the compositor going down. Right now the assumption is
that dead X server == dead session, since there is some minimal
session management built in there (also because normal users couldn't
for the longest time run the X server, so it was assumed that the
privileged user would start it up again and bring it back to XDM)

>
> The way the client will detect when the new compositor is available is by
> following exactly the same rules they use when the first start up to locate
> the compositor. If for instance when a client starts it attempts to open a
> named pipe, this is exactly what it will do after the previous compositor
> exits. If it fails to open it probably should try repeatedly with a timeout
> between each try, and only exit with an error after a very long time (30
> seconds or so). This will give time for the compositor to restart, and would
> also solve the current problem where you can't launch a compositor and a
> bunch of clients simultaneously.
>
> Besides handling crashing, this should also be the way to switch
> compositors. A compositor could actually force a client to a different
> compositor by first modifying the client's environment in whatever way is
> needed so it will connect to the new one, then closing the connection.

This is quite handy for networking too.

>
> On Mar 6, 2011, at 10:04 AM, Marty Jack wrote:
>
>>
>>
>> On 03/06/2011 12:41 PM, nerdopolis wrote:
>>>
>>> Hi.
>>>
>>>
>>> I just want to bring this up for early consideration:
>>>
>>>
>>> It seems that many things in Wayland will be determined by they type of
>>> compositor server you are running, such as if you want to have a tiling
>>> window manager in Wayland, or one that has other features.
>>>
>>>
>>> My question is that will users be able to have the ability to change
>>> their Wayland servers on the fly? not only would such a thing allow the
>>> users to change functionality, but it will also help in the case if the
>>> Wayland server goes down, where the session is not lost.
>>>
>>>
>>> Will this have to happen in the apps themselves? If so, how would the
>>> apps "know" that the socket (or maybe even a new socket) is available for
>>> reconnect?
>>>
>>>
>>>
>>> _______________________________________________
>>> wayland-devel mailing list
>>> wayland-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>> An interesting point.  A parallel to <window-manager> --replace, and
>> probably something that users would want to do while they are experimenting
>> with different looks.
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
Sam Spilsbury