Galaxy Communicator Documentation:

Using the Hub in Scriptless Mode

License / Documentation home / Help and feedback

As of version 2.0, the Hub does not require Hub programs to run. The Hub still requires a configuration file, because it still must know how to do its logging and how to contact servers. In this document, we discuss some of the options available to the developer for scriptless interaction.

Omitting Hub programs

Currently, we have chosen to implement scriptless interaction by making Hub programs optional. That means that a Hub program file need not contain any PROGRAM: or RULE: declarations in order for the Hub to function. The user may still choose to provide any of the global declarations; server declarations are still required, and the only way to enable logging is to use the logging parameters.

When the Hub receives a message and there is no program to claim it, the Hub searches its list of servers for a server which has declared an operation which is identical to the message name. Let's say the Hub receives a message of this form:

{c parse
   :input_string "I want to fly to Denver" }
If there is a Hub program named parse, that program will claim the message and process it, regardless of whether there's an operation named parse. In the following program file, the message sent to the parser server will be parse_string, not parse:
SERVER: parser
OPERATIONS: parse parse_string

PROGRAM: parse

RULE: :input_string --> parser.parse_string
IN: :input_string
OUT: :frame

However, if there were no program named parse, the Hub would pass the incoming message directly to one of the providers for the parse operation, and the parse operation would be invoked. The specific provider is chosen according to the rules for provider selection.

What this means is that the developer doesn't need to choose fully scripted or fully scriptless; it's possible to construct a "partially scripted" program file, where some new messages are claimed by programs and others are not.

Logging

Previous to version 2.0, it was possible to log only the invocation of a program rule. This meant that logging in scriptless mode would have been impossible. In 2.0, it is possible to log incoming messages and their returns to the calling server. We give a brief summary here; see the logging documentation for details.

First, the TIMESTAMP: declaration now applies indiscriminately to operations and programs:

SERVER: parser
OPERATIONS: parse parse_string

TIMESTAMP: parse parse_string

PROGRAM: parse

RULE: :input_string --> parser.parse_string
IN: :input_string
OUT: :frame

In our example here, the log will contain a timestamp for when the parse request arrived on the Hub, as well as when the parse_string operation was sent to the parser server. Because timestamps are indiscriminate, the program doesn't have to be present in order for a timestamp to happen; so if the parse program is removed, the incoming timestamp will still happen.

Second, it is now possible to add LOG_IN: and LOG_OUT: declarations outside the scope of a rule, and the new MESSAGE: declaration supports in and out logging for scriptless rules. So either of the following program files will result in a time being recorded for the incoming parse message:

SERVER: parser
OPERATIONS: parse parse_string

TIMESTAMP: parse parse_string

PROGRAM: parse
LOG_IN: :input_string

RULE: :input_string --> parser.parse_string
IN: :input_string
OUT: :frame

--------------------------------------------------

SERVER: parser
OPERATIONS: parse parse_string

TIMESTAMP: parse parse_string

MESSAGE: parse
LOG_IN: :input_string

In this way, all the possibilities for logging are still available for scriptless interaction.

Writing your own scripting module

In principle, it is possible to write your own scripting module, by altering the SCRIPTING variables in config.make and providing your own library which implements the scripting API. However, we have not tested this functionality. We do know that because we use MIT scripting to provide server and logging declarations, your scripting module would currently have to supply equivalent declaration facilities.

License / Documentation home / Help and feedback
Last updated May 23, 2002