View source for Disconnecting from server while still saving an animation

=Overview=

Typically, when a client disconnects, the server process terminates. Thus, for the server to do any processing, a(the) client must be present. This becomes cumbersome especially when generating large animations, since now it is required that the client remains alive till the entire animation is generated. ParaView3 supports a mode in which it is possible for the client to disconnect from the server and then tell the server to generate and save an animation. The server generates the animation and then exits. This document describes the UI and the internal design for the same.

=User Interface=
* This mode is only application when saving an animation on a remote server.
* If the connection is a remote connection, then the save animation dialog has an additional check box "Disconnect before saving animation.". This must be checked to disconnect the client before saving the animation.
* It must be noted that the animation will be saved on the root node of the server (data server) in this mode (normally, the movie is saved on the client).
* Once the user accepts, the connection to the server will be closed, the user will loose all the pipelines he/she had setup on this particular connection.

=Design=
* Animation is a Server Manager feature. Animations are generated by changing properties on proxies using vtkSMAnimationSceneProxy/vtkSMAnimationCueProxy etc. Thus, to play an animation on  the server side without a client, it is essential that we have a server manager on the server side as well. Hence, ParaView3 server (data server) now creates and initializes a Server Manager (Server-side Server Manager or SsSM) when is starts. 
* The SsSM is not an active server manager. The client uses the local Server Manager for all proxy creation etc etc. 
* Disconnecting and playing/saving an animation on the server has two parts:
** Synchronize the SsSM with the client side ServerManager and '''revive''' it.
** Generate the animation.

==Reviving the Server-Side Server Manager==
* To revive the SsSM we first need to save the state xml of the server manager on the client side. We don't want to simply load this state on the SsSM, since that would lead to creation of new server side objects for all the proxies. Hence this state xml has additinal elements we call '''revival state''' which includes thing such as object IDs for the server side objects.
* When this '''revival state''' is loaded on the SsSM, it creates new proxies but initializes them to use the already existing server side vtk objects. All objects that are client-only are now recreated on the server.
* We don't revive render modules and displays since the rendermodules/displays have to be different depending on whether it's a remote server connection or not. Hence, we create new render modules/displays appropriate for the server side, however load the properties from the state of the client side render modules so that physical properties of the rendermodules on the client and the server are similar.
* All this is managed by the class '''vtkSMServerProxyManagerReviver'''.

==Generating Animation==
* To generate an animation on a '''revived''' SsSM, we want the animation generation to start after the client has disconnected. Thus the client can't directly send a command to the server to start playing the animation after it disconnects.
* For this, we have what we call '''ConnectionCleaners'''. These are server side objects that perform some cleanup operation on the server when a particular client-connection is closed.
* To play an animation on the server, we simply create a "AnimationPlayer" proxy before we revive the SsSM. The server side object for this AnimationPlayer proxy sets itself up to listen to connection disconnect events from the process module. 
* As soon as the connection closes, the server side object activates the SsSM and starts playing/saving animation. Once done with the animation, the server terminates normally.