Connections Settings
If enabled, a server process is started within smalltalk,
which handles ans 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 scripts, or to open smalltalk-dialogs from
non smalltalk programs (shell-scripts).
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.
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).
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 '"
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.
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.
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.
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).
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).
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.
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 server directly, or in
slave mode, under control of a real apache server, where requests are forwarded via
the FCGI interface.
The HTTPServer settings are documented in a separate document:
"HTTPServer Help Index".
Copyright © 1999-2006 eXept Software AG, all rights reserved
Doc $Revision: 1.5 $