Communication Settings

Help index


Remote Doits Enabled

If enabled, a server process is started within smalltalk, which handles and serves "RDoit" requests. These allow smalltalk expressions to be evaluated via the rdoit shell command (the source of the rdoit program is found in the "goodies/rdoit" directory).
This is especially useful, to start smalltalk applications via the window manager or from shell/batch scripts, or to open smalltalk-dialogs from non smalltalk programs (shell-scripts). It can also be used to access Smalltalk services from other non-smalltalk applications. As Smalltalk also provides an rDoit client, it can also be used for a very simple smalltalk-to-smalltalk remote procedure call mechanism.

Warning

RDoit expressions are not evaluated in a secure environment; if enabled, any expression (even destructive) can be evaluated via the rdoit command.
Although exceptions are cought, a bad guy could send you something like "Smalltalk exit" and finish your smalltalk session. Even worse attacks are possible, by sending something like "OperatingSystem removeFile" to harm your system, or "OperatingSystem executeCommand", to install a virus.

In order to provide a bit of security, the RDoitServer opens a confirmation dialog for every new host trying to connect. This allows denying requests from other hosts.

Also, the rdoit server can be configured to either serve a tcp socket or a unix-domain socket (not under Windows, of course).
Using unix domain sockets, you can ensure that rdoit-evaluations are only possible from the local machine.
Do not enable this feature, if your machine can be reached via untrusted machines (i.e. the internet). Only enable this to a limited set of machines in controlled environments. For example, to partners in a programming team, or to a cooperating host in a secure, controlled multi-machine control application. Never allow for untrusted humans to enter the rDoit command string without validation against a set of allowed, harmless commands.

The "rdoit" command

The rdoit command (i.e. the reqestors code) is provided in source in the "goodies/rdoit" directory. It may be useful to install this command in "/usr/local/bin" or any other directory along your shell PATH.

Two example shell scripts are provided: edit.sh, which opens a smalltalk editor, and fb.sh, which opens a file browser.

The other check boxes in the settings dialog control if logging information is to be sent to smalltalks transcript or standard output (i.e. the xterm).

Example


Suppose, you have installed the rdoit executable program in your path, you can evaluate smalltalk expressions from the UNIX shell as:
    rdoit "SystemBrowser open"
or, to print the result of some expression:
    rdoit -p "1000 factorial"
or, to open a dialog:
    rdoit -p "Dialog request:'How are you '"

The RDoItClient class

For smalltalk-to-smalltalk communication, the rdoit functionality is also available in the RDoItClient class.


JS-Scripting Enabled

If enabled, a server process is started within smalltalk, which handles and serves "Scripting" requests. These allow expressions in a JavaScript-like syntax to be sent to and evaluated by ST/X. It is also useful to provide remote-control capabilities to a standalone enduser application.

One particular application is to remote control an application for automated tests (such as regression tests of GUI applications using the eXpecco testing framework.

Being completely text-based, with a simple message format, it can also be used to access Smalltalk services or services of a standalone application written in Smalltalk from other non-Smalltalk applications.

Warning

Script expressions are not evaluated in a secure environment; if enabled, any expression (even destructive) can be evaluated via the scripting interface. Although exceptions are cought, a bad guy could send you something like "Smalltalk.exit()" and finish your smalltalk session. Even worse attacks are possible, by sending something like "OperatingSystem.removeFile(...)" to harm your system, or "OperatingSystem.executeCommand(...)", to install a virus.

In order to provide a bit of security, the ScriptingServer can be configured to only allow connections from the local host or to limit access to a small group of known hosts. However, even this is not 100% secure. Therefore, scripting should only be enabled and used in a secure lab-environment.

Do not enable this feature, if your machine can be reached via untrusted machines (i.e. the internet). Only enable this to a limited set of machines in controlled environments. For example, to a partner in a programming team, or to a cooperating host in a secure, controlled multi-machine application. Never allow for untrusted humans to enter script commands.

Connecting to the Script Server

Any line oriented connection program can be used to talk to the scripting server. A wellknown and generally available tool is "telnet". Don't forget the port-argument.
Suppose, you have started the scripting server to serve its default port 8008. You can then evaluate scripts from the UNIX shell or MSDOS command prompt via:
    telnet localhost 8008
You will get a prompt with additional usage information.

Example

An example session is:
    telnet localhost 8008
    Welcome to ST/X (Type ~? for help)
    > 1+2;
    3
    > 10.factorial();
    3628800
    > var v;
    > v = View.new().open();
    a View
    > v.viewBackground( Color.red() );
    a View
    > v.clear();
    a View
    > v.destroy();
    a View
    > ~.

Starting an Applciation with Scripting enabled via Stdin/Stdout

[... to be implemented ...]


OSI-ACSE Logging

These checkBoxes are only enabled, if the addOn OSI-ACSE-Protocol package (*) is present in the ST/X system.

If enabled, errors, connection-related events and data transfers are logged on the standard-error.
The default is off.

OSI-ROSE Logging

These checkBoxes are only enabled, if the addOn OSI-ROSE-Protocol package (*) is present in the ST/X system.

If enabled, errors, remote operation invocations and responses are logged on the standard-error.
The default is off.

OSI-CMISE Logging

These checkBoxes are only enabled, if the addOn OSI-CMISE-Protocol package (*) is present in the ST/X system.

If enabled, errors, CMISE messages (m_get, m_set, m_action etc.) are logged on the standard-error.
The default is off.

(*)
This is a non-free addOn package, which implements the OSI protocol stack in smalltalk. Please contact exept for availability and pricing.


SMTP Server Configuration

The SMTP Server is responsible for email-delivery to other systems. The values defined in this dialog provide default values for the email delivery options in the debugger (to email an error report) and the browser (email class-source to).

Window Migration Enabled

The window migration feature allows for smalltalk windows to be grabbed from another display (X-displays only). I.e. it allows you to actively ask for a window to be moved and reopened on another machine (sending this request from the other machine).

Remote Browsing Enabled

The remote browsing features allows for a SystemBrowser to be opened on and inspect another running image.
This allows multiple programmers to work simultaneously in a single image.

Warning

Enabling remote browsing opens a possible security hole, in allowing others to modify the code which is executed by your running smalltalk system. It should never be enabled, if your machine can be reached via untrusted machines (i.e. the internet).

SmallTeam

The SmallTeam subsystem allows for multiple smalltalk developers to automatically pass information about changes in the code to each other. Technically, change messages as normally written to the change-file are also sent to other team members. The Systembrowser is aware of such changes and marks classes and methods which have been changed by other team members. Also, the SystemBrowser provides explicit smallTeam synchronization functions in its class- and method menus.

SmallTeam Server Enabled

Enables the SmallTeam service, which allows for other Smalltalk/X users to be notified of changes done in your image and to automatically synchronize their images with yours.
This has no effect on your image, but allows read access to other users.

Warning

Enabling the SmallTeam service opens a possible security hole, in allowing others to load pieces of code from your running smalltalk system, and also allows for untrusted code to be imported into your system. It should never be enabled for untrusted machines.

SmallTeam Hosts

Defines the list of hosts which are allowed to connect to your SmallTeam server and to which change-notifications are send whenever code is changed in your image.

DotNET Bridge

The DotNET bridge functions as a message forwarder to and from the microsoft .NET environment. In addition to message marshalling and forwarding of messages, the bridge also keeps track of object-references and provides a .NET-object proxy mechanism for smalltalk. This allows for smalltalk code to handle .NET object almost transparently like any other object (with a few exceptions).

Verbose

Enables protocol debugging. If enabled, incoming and outgoing messages are recorded in the Transcript window.
This is probably only useful to developers of the bridge.

Running in IDE

If enabled, the .NET-part of the bridge is assumed to be started in the Visualstudio IDE environment, and the communication between smalltalk and .NET is via a fixed port number. If disabled (the default), the .NET-part of the bridge is started as a subprocess from smalltalk, and the communication port number is passed as command line argument.
This is probably only useful to developers of the bridge.


SQLServer

The SQLServer implementation consists of an SQLParser and an associated socket interface server, which allows for SQL requests to be sent to the smalltalk system via a standard ODBC based database client.
Hereby, the smalltalk system "mimics" the behavior of an SQL database engine; however, the generation of results (rowsets) is completely under control of a smalltalk class. Therefore allowing relational access to arbitrary smalltalk objects.

This is an experimental, nonfree addOn feature, which is available upon special request.


HTTPServer

The HTTPServer framework provides functions comparable to those provided by other well known HTTP servers (such as apache).
It can either run in master-mode, where the HTTP-socket is served directly, or in slave mode, under control of a real apache server which serves the HTTP-socket, and forwards requests to smalltalk via the FCGI interface.

The HTTPServer settings are documented in a separate document: "HTTPServer Help Index".


Copyright © 1999-2008 eXept Software AG, all rights reserved


Doc $Revision: 1.13 $