GSoC: Hot-Replace Server

[Kai Mast]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey guys,

thanks for all your answers to my mail. I created my application for
the GSoC. Would be cool to get some more feedback before I turn it in.


GSoC 2011 Proposal: Hot-Replace Functionality in Wayland

    = Introduction =
Because Wayland unifies the compositor, displayserver and
windowmanager into one process it is not possible to change the
windowmanager or compositor at runtime, like one is used to in a
normal X-Environment. The goal of this project is to allow a
replacement of the Wayland Server during runtime of client-applications.
Additionally, this could allow applications to keep running after the
XServer crashed.


    = Brief overview over the design =
At the moment Wayland already keeps very little information about the
states on the sever-side. That means if the client-implementation is
extended properly we could add the ability to recreate the state of
the application before the server went down.
Therefore we need to implement a shutdown procedure where the server
tells the client that it is being replaced by another one. Also the
client needs to behave differently on a disconnect than on a timeout
of the connection, which could mean that the server has crashed and a
new one is about to start up.
It has to be decided, if either the clients wait for some time and
then try to reconnect to the server or if there is some kind of
application directory where the server can look up running Wayland
applications and then connect to them. Both designs have benefits and
disadvantages. I personally would prefer some kind of application
directory.
The servers may also support different kind of protocol extensions
(e.g. a specific GNOME-Protocol) so clients must query server-features
on reconnect and if needed change their state accordingly.
Also, the window IDs should be changed and be a tuple of a process-id
and window-id so the window-id don't have to be dropped on the client
side.
Restarting of the server should be handled by ?/sbin/init? or similar
replacements like upstart or systemd.


  = Brief overview over the implementation process ==
1. Define a default behavior and protocol for this case and publish
the specifications. Also create testcases and discuss possibly
drawbacks and advantages of different implementations.

2. Implement the protocol in libwayland-server and libwayland-client.
Add the features to the sample compositor.

3. Additional work, create upstream patches to toolkits if some time
is left for that. Add a notification system so the desktop
environments can tell the user what happened to the compositior.


 = Deliverables =
Fist, a more flexible libwayland that allows the described kind of
functionality and creates a base for further features that may not
have been implemented during this Summer of Code project, like crash
notifications or the ability to change the video driver.
Secondly, having the sample compositor supporting this behavior.


 = Proposal for a road-map =
I will work on this project aside to my university studies and then
full-time when the semester ends. As I'm really interested in Wayland
development, I am also willing to go on with development after the
summer project ended officially.

May
1. Get some more involved into the design of Wayland, especially how
buffers are shared between client and server.
2. Propose an amendment to the protocol and define the
reconnect/replace-behavior
3. Create an application-directory

June/July
1. Update libwayland-client and libwayland-server accordingly
2. Simultaneously test the behavior by implementing the needed
features in wayland-compositor

August
1. Bug fix the implementation
2. Create upstream patches for toolkits to use this behavior too
3. Add a way for the desktop environment to find out what happened to
the server and notify to user.


 = About Myself =
I'm a 20 year old computer science student in the University of
Bamberg, Germany.

Being 13, I read my first book about the C programming language and
since then I've been constantly learning more and more about
programming. Since then if been involved into different projects. I
was especially interested in game development and during the time
gained good experience in the use of OpenGL and the Architecture of 3D
engines. Also I've been working with network-sockets and OpenAL.
I've been using Linux since 2007 and have used it exclusively since then.
During the last years of involvement with free software, I also became
politically active and tried to inform people in my area about the
concepts of network neutrality, copyleft licensing, open government
and freedom of information.

I hope with participating in this project I can learn more about the
architecture of a display server and give something back to this
wonderful community of developers.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNnPRGAAoJEKU5B2k1XeME9xkP/2Z+psseQp+pS1envJpXu5j7
+ehIUfY8u8ZvTt/eHcesid4vnEzaJdHbZ/en7S0sWCJuWR8b1j5bl9V++s3X1gDY
cNVIv1BoScwiqVrlIuqju/DYDHSUXE/DseaOltHOORjcm7HJlJZZxRpX2PSM+Dk0
QC17SH8DlDFR4GZcc03X3SV2X8WPon5G6fKlo8JCLKVFfwZ+fld0jTh2y3ZDoHsU
xo6+OlGn7wIEfqA3qq14GCwpWqbPZa4RFe2SS1TfW/5vAbGMcw7I8orTZ0i0kXML
CRvfuQUNAH5347BdJC8dZ4yZrmmk572bnY+JxSEpm0inI0cUxIb1wCIzE1APUioQ
zzPNQKHBYrEiJe/u7KPDgdctJv05rFQB+4oT+0A0FD7bnT97Q7IUXMaI/JKWOdGp
RCa3koKsbUXnF49PuQVmV6LjXycBixiNryRJ3NAyMKe5+jFoXciEy2Uo61xgpqtY
o76qrTolQiCD5OJIzWOpZUk7yeO7Q8Vgu7kidHAvoRH0mE5KFbWjE2S8JJcwgUQb
r+zFHO0mlGMde1EvlaEtuojNfOr923GGFhoEpofTIobbx6EurfwelgZb2N+NoXE5
DJRzv42J7yiPDPNhS1JPpb2TRIwhujiI/qVvR2aLbr5kOJNkHdDh31udb4Grh/3f
R4HP3MX8hkE+AORp3+5x
=oNgQ
-----END PGP SIGNATURE-----