Communication Settings
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.
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 ...]
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 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).
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 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.
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.
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.
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).
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.
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.
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 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 $