FWD » Core Development » User Interface

This task is no longer needed.

The initial idea was that server-side applications (batch programs, appserver, webspeed...) would be able to leverage features normally designed for client-side usage, but that these features would be executed inside the server process. Upon further consideration, this idea won't work. The basic reasoning is that these client features all entail state that can be different for each process. In the 4GL, the appserver support is really implemented using multiple 4GL client processes and every batch program is likewise a separate client process. This means that these processes each have their own state. If that state was resident in the P2J application server and had a Java-backed representation, then it could be "virtualized" to separate each "process" from one-another. But each of these client-side features has state that exists at the operating system level (e.g. the current directory for a process, file descriptors or the environment) and/or in 3rd party code (e.g. DLL instance data). This state is outside of the control of the Java server and thus we must actually retain the multi-process client design of the 4GL. The processes will still run on the same server system, but for each appserver/batch process there must be a corresponding client process that can be used to execute/contain these features.

In the case of terminal redirection, there is no advantage to moving it to the server when we are already required to have a client process. In fact, that redirection would be potentially dependent upon the the current directory, the client process' psuedo-terminal and other operating-system level state like the ncurses environment which has process-specific state.