[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freenx-knx
Subject:    [FreeNX-kNX] Session Resume Ideas
From:       jon () severinsson ! net (Jon Severinsson)
Date:       2005-04-25 21:19:49
Message-ID: 426D5EF5.7040600 () severinsson ! net
[Download RAW message or body]

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

Hi again and thanks for all your responses. I'll try to reply to all of
you in turn.

Kurt Pfeifle wrote:
>> 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,
>
> It will be auto-resumed, if you use the same session-name
> (in !M NX Client labelled "Session" on the initial dialog
> screen), and if the geometry/color-depth of the display
> you use matches the running nxagent.
>
IMHO behavior should NOT be based on session name, but rather the
parameters I listed (type and geometry/depth, and possibly command or
agent-server).  This is as it is (or at least should be) the parameters,
and not the name, that determines whether resume is possible, and
wanted.  You might also name identical sessions different on different
clients (ex. "My_Server" on my own computer, but "Jons_Server" on my
dad's computer), and still like to resume on another computer than you
suspended it with.


Fabian Franz wrote:
>> 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.
>
Well, this is not 100% true.  I have had multiple suspended sessions
(with identical session name) and not getting a list.  Instead both the
first and second new connections made to the nxserver autoresumed one
session (ENABLE_AUTORECONNECT was disabled!).
I have also had lists with only one session in them.
But now I at least know what's supposed to happen.

>> 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 (i.e. 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.
>
I can understand your argument, but IMHO session name is not the best
way to determine this.  I'd rather base it on session type instead, and
possibly offer a directive to enable the commercial way of doing it.

>> As long as the backend doesn't support reconnections in a different
>> resolution (i.e. 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.
>
Good enough for me.  Should not affect whether the list appears or not
though (i.e. if no sessions can be resumed the list shouldn't appear).

>> 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.
>
Yes, I know.  This is mainly a wish-list of how I think it *should*
behave.  Implementation comes later.

>> 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.
>
Or at least supposed to...

>> 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.
>
I think that should be configurable, but disabled as default (as it
should be possible to create a new session without having to reconnect
to the old one, create a new session, and then re-suspend the old session).

> We could add an option to add some $random to the name to disable this
> behaviour.
>
Do you mean that the backend (nxagent) will reconnect even if we give it
a new unique session id?  IMO that would be a bug, and should be fixed.
 If nxserver generates a new session id instead of supplying an old one
nxagent should not resume an old session!  No $random should be needed
to implement this.

>> 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 know this.  Included for completeness.

> I hope this gave you an overview what is already done and what needs
> work.
>
Yes, thank you!


Kurt Pfeifle wrote:
>> 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.
>> This list should NOT contain any sessions of another type than the
>> requested (i.e. if you ask for a 'unix-kde' you should not be offered
>> to resume a 'unix-gnome' or 'unix-custom').
>
> I do not agree.
>
> I may be very busy (in fact I very often am) with connecting to
> various (Free)NX servers. But for some of them, I may come back to
> the same server only after one or two weeks. After that time I have
> forgotten which type of session there is suspended (or even still
> running from another NX client).
>
> I find it quite convenient to see a list of all my running/suspended
> sessions on a particular NX server once I try to connect again --
> because I can also then decide to "terminate" one or more of the
> older sessions before creating a new one or re-connecting to one
> that is still alive.
>
OK, I see your point.  What about including them in the list (with a N/A
status) if there is a list but not let them determine whether the list
should appear (i.e. if no sessions can be resumed the list shouldn't
appear).

> I do not think we should make matters more complicated than they
> are already. The concept "Connect to one NX server -- and if possible,
> list me all sessions which are still alive so I can decide what to
> do with them" is as simple as it can get. (With the simplest option
> being "Connect immediately, if you can (because all parameters match
> to a running session".)
>
As above I agree, except for the "Connect immediately" thing.  When
there is two or more suspended sessions I can choose to create a new one
instead of resuming a suspended one.  Why not when there is only one
suspended session?


LROUFAIL at nc.rr.com wrote:
> 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.
>
This would be great!  Unfortunately I'm not a very good C++ hacker.
Want to learn though, so if I get some time to spare... (perhaps during
summer break, if no other kind soul has done it by that time.)

> 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.
>
Great, that would make full resume support to NXDriver to just ask for
and parse the list sent by the server!


Thanks all of you for your response!

Regards
- - Jonno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCbV71OOpxqcksWu4RAt/AAKChSxP36KHjrL8rWPiO9igxSKcuQQCfTeVS
1+LXNaibTzPrd62f6Vjxois=
=2NVu
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]