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'?