Pedro-
You are talking about what I would call "stateful"
applications or application servers. A quick search turned
up something about the BEA application server, but the
Tarantella product from SCO is the first thing that jumped
to my mind. Unfortunately, these products use web
technologies, like Java, to deliver their apps to the
viewer software. You would, therefore, have to beef up
your text-only workstations to be able to use them
(assuming low-end stations, hence text only; if your
stations are X capable, then by all means, run with it).
Another option is VNC. I believe VNC is stateful, though I
haven't investigated this capability of VNC personally.
Someone recently mentioned a DOS client for VNC, which
would fit into your low-end terminals. I also take it one
could somehow use VNC to serve up a single application
instead of an entire desktop.
If you want a clean solution without having to make the
jump to graphical terminals, then what you want is
basically the following:
<terminal> -- <stateful layer> -- <application server>
instead of
<terminal> -- <application server>
(Most likely, the stateful layer will reside on the
application server. This is not necessary, though. The
application server could be on a third box. The only
requirement is that the stateful layer not be at the
terminal, of course!)
The terminal will initiate a request for an application.
The application server will start the app and its output
will be directed to the "stateful layer" (whatever that
is). The terminal will then interact with the stateful
layer. If the terminal dies or communication is cut or
whatever, the stateful layer is still running and
communicating with the application server and your terminal
should be able to reconnect to the stateful layer and pick
up where you left off later.
It sounds like it would be best to have the whole text
session (starting with logon) in the stateful layer, rather
than specific applications. A process that runs as the
user immediately after login, perhaps instead of the
shell... It would have to be reparented as a child process
of init so that it doesn't die if the user's session is
unexpectedly terminated. If the user logs in and the
program starts but finds a copy of itself already running
for this user, it simply connects the new login session to
the existing stateful session... Of course, this dumbly
assumes only one simultaneous session per user. One would
thus have to encode some kind of session-id into the
stateful layer instance so that the new invocation can
check to see if the associated session still exists.
Okay, back to your question...
It sounds like this is all quite possible, theoretically.
Whether it's already a project on Sourceforge or something
is another matter. It shouldn't be too hard, however, so I
imagine that someone somewhere has done it. My quick
search didn't turn up anything, but I didn't try very hard.
Hopefully I've at least given you some more search terms
to play with... and perhaps even some ideas on where to
start writing your own implementation. A project like this
could be very useful!
Anyone else here heard of anything that does this? If not,
further posts should probably be off the list because this
is pretty off-topic.
Jason
> Date: Sat, 1 Jun 2002 12:36:42 -0700 (PDT)
> From: Pedro Torres <[EMAIL PROTECTED]>
> Subject: [Ltsp-discuss] (no subject)
>
> i need to know if i can restore a ltsp console
> terminal (text base) from a abnormal power off (or
> anything like) to the state before occurs the power
> off.
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.openprojects.net
