[FreeNX-kNX] Session Resume Ideas

[Fabian Franz]

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

Am Montag, 25. April 2005 14:41 schrieb Jon Severinsson:
> Hi everyone

Hi,

>
> I have been doing some thinking on resuming.  Currently it seems as if
> it is purely random (of course it isn't, but I haven't found the pattern
> by try and error) if a session will be automatically resumed, or if the
> list of choices will appear, and what sessions is included in the list.

Its easy:

- - If there is just one session and it has the same name as the old session, it 
is automatically resumed (in the commercial server even with running 
sessions)

- - If there are several sessions you get the window.

The server says, which status a sessions has: E.g. running, suspended, N/A 
(not available).

> Logically (that is in our minds, but not necessarily in code) first step
> in making a connection (after authentication) is to make a list of
> available sessions.

Ok.

> This list should NOT contain any sessions of another type than the
> requested (ie if you ask for a 'unix-kde' you should not be offered to
> resume a 'unix-gnome' or 'unix-custom').  In the case of a 'unix-custom'
> session the requested command should be the same (if I ask for kcontrol
> I don't want to resume a ksysguard session), and in the case of a 'vnc'
> or a 'windows' session the agent server and username should also be the
> same.

==> I agree that this behaviour should be configurable, but not default. As I 
would like to default to the same behaviour as with !M nxserver.

> As long as the backend doesn't support reconnections in a different
> resolution (ie not until 1.5) the list shouldn't contain sessions in a
> resolution other than the requested.  

Those sessions are put in status "N/A" and the client won't reconnect those.

> After 1.5 is available, this
> should be configureable.

Ok.

> If ENABLE_RECONNECT_RUNNING is enabled then this list should contain
> running sessions as well as suspended ones.

==> Ok, but we need to add this functionality first. There are some problems 
with that, as you need to wait a certain time for the session to be suspended 
until you can resume to it.

>
> Now, if ENABLE_AUTORECONNECT (or, in case of nxclient 1.3.x,
> ENABLE_AUTORECONNECT_BEFORE_140) is enabled the first session on this
> list that is suspended should be resumed.  

Its done like that already.

> If no suspended session is on
> the list, a new session is automatically created (unless SESSION_LIMIT
> or SESSION_USER_LIMIT is reached, in which case the connection will fail).

Done like that already.

>
> If ENABLE_AUTORECONNECT is dissabled and the list contains any sessions
> at all, the dialog should appear at clientside where the user can choose
> between the session on the list and creating a new session (unless
> SESSION_LIMIT or SESSION_USER_LIMIT is reached, in which case that
> option is disabled).  

Done like that, but if there is just one session its automatically resumed if 
it has the same name.

We could add an option to add some $random to the name to disable this 
behaviour.

>If the list is empty, a new session should be
> created automatically (unless SESSION_LIMIT or SESSION_USER_LIMIT is
> reached, in which case the connection will fail).

Done already like that.

I hope this gave you an overview what is already done and what needs work.

cu

Fabian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCbRQ4I0lSH7CXz7MRAgGjAJ44jHYLbEd19TmfsIc9YgAz5XQGhACaA0JD
DNrfvBLZLO6KrJZ8IAl6GB8=
=hUIz
-----END PGP SIGNATURE-----