[FreeNX-kNX] Session Resume Ideas

[LROUFAIL at nc.rr.com]

Incidently, I would like to add the session list functionality to 
NXDriver so that all open source clients can handle this functionality 
in a consistent way.  I have limited time, so if anyone has C++ skills 
and would like to lend a hand, please let me know.

Currently, you CAN resume sessions with the open source clients, 
because the default rules will kick in.  Also NXDriver can be given a 
session id (if you happen to know it) and it will resume that session.

Thanks,

Lawrence

----- Original Message -----
From: Fabian Franz <FabianFranz at gmx.de>
Date: Monday, April 25, 2005 12:00 pm
Subject: Re: [FreeNX-kNX] Session Resume Ideas

> -----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-----
> 
> _______________________________________________
> FreeNX-kNX mailing list
> FreeNX-kNX at kde.org
> https://mail.kde.org/mailman/listinfo/freenx-knx
>