Here is a new design note from the communication team :-).

INTRODUCTION

Unfortunately, the former design was not suitable for the kind of things
we want to do. This does not mean it would not lead to a clean and portable
solution, but it would have required to much "system" work. Besides, that
system work would have simply duplicated what existing tools like 'rlogin'
and 'ksh' already provide us, namely:

1) The authentication mechanism for the remote login process. This relies on
the system's authentication abilities to perform all the security checks.

2) The terminal driver is directly handled by the rlogin+ksh application. It
is necessary to provide a terminal driver in case the user wants to debug
'curses' applications or whatever requires terminal support.

3) The 'xterm' program provides us directly with a pseudo-tty driver under the
X11 windowing system--something we need desperately.

The previous scheme was implementing the 'rsh' part of the problem, but the
terminal part is much harder to do. Philippe and I though it would be best
to avoid focusing too much on what the existing system tools already give us.
Therefore, a new direction must be taken.

Let's say it right away: the new scheme requires user's intervention. But it
brings so much flexibility and ease of use that it must not be considered as
a weakness in the system. Saying that would be the same as rejecting the
environment variable "DISPLAY" in a X11 windowing system.

THE WORKBENCH

The user starts the 'ewb' process and receives an identification number which
must be unique across the whole internet. Something like "machine:number"
where 'machine' is the host name and 'number' is a computed ID which should be
unique during the whole life of the machine.

He then decides on which machine M he wants to run the application and he
requests the workbench to connect itself to the remote 'ised' daemon on that
machine. Once this is done, the user must issue an 'rlogin' on that machine
and set the ISED environment variable to the cookie the workbench gave him
when it started.

THE DAEMON

The 'ised' daemon runs as root and does not play any active role in the
communication process. It simply acts as a relay and an initiator.

When invoked, the daemon opens the white pages file 'wp' and computes an
unique path name in /tmp, say /tmp/ised-0001. It then maps this pathname to
the cookie received by the associated workbench, opens the file as a named
socket or named pipe and goes to sleep (a kernel-induced sleep).

The daemon will wake up as soon as someone opens the named socket or pipe
for writing. Then, it will immediately act as a 'blocking' relay, which
means its I/O communications with the other end of the named socket or pipe
will be blocking ones. Everything which comes from the application is
immediately routed to the attached 'ewb' process while everything coming from
that process will be written into the application.

THE APPLICATION

Upon start up, the application looks at its 'ISED' environment variable and
looks into the white pages to find the name of the named socket. It then opens
it for writing (hence waking up the daemon waiting on the other end) and
is ready to start its processing, connected to the remote workbench.

DISCUSSION

Pros:

There are many advantages with this new solution:

1) The user is free to run whatever commands he wishes, intermixed with Eiffel
executables. For instance:

	first 2>&1 | eiffel_program <&- 2>errors | last < toto

2) The user works within his own environment, with his own shell and aliases.

3) There is little burden on the application. In fact, the communication socket
is only activated when the process stops within the byte code (because a
breakpoint was set, for instance).

Cons:

There are also a lot a problems:

1) The user cannot mix two Eiffel programs within the same command:

	first_eiffel_program | second_eiffel_program

is verbotten. By Eiffel programs, I mean of course programs frozen in a
workbench context.

2) If the workbench on the remote machine hangs or dies for whatever reason,
the user must reset the ISED variable correctly.

3) The user must not forget to set its ISED variable. Otherwise, the application
will think it is not invoked in a workbench mode and will execute its frozen
code. This might lead to big surprises.

4) There is no system way to prevent two processes from writing into the same
named pipe or socket. This means if in one window the user runs an application
connected to workbench #1, then in another window, he cannot run any process
that would connect to workbench #1 also. The point is that if he does do it,
then impredictable results would occur. The problem is that this cannot be
detected and thus prevented.

5) The white pages file will grow up for ever.

Other problems:

The following problems remain unsolved by both schemes. They are related to the
communication problems but do not fall directly under my current "job".

1) There is no way for the workbench to tell whether the Eiffel program the
user ran indeed matches the one currently under "workbench control". That is
to say, if I am debugging 'toto' and I am running 'titi', another Eiffel
program, how do I detect this?

2) How do we know the frozen version of the Eiffel executables matches the
idea the workbench has on it. If I am starting 'toto.00' instead of 'toto.04',
what if the workbench thinks 'toto' is in state '04'?