Scripting ideas

From GNUstepWiki
Revision as of 09:37, 18 February 2005 by Stefan Urbanek (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Shared Scripting Environment Process/Server

Scripting from an UNIX shell

Create a shared scripting environment process test

> stalk --create test

Execute some scripts in the environment called test

> echo "Transcript showLine:'Hello!'" | stalk test
> echo "name := 'StepTalk'" | stalk test
> echo "Transcript showLine:('Hello ', name, '!')" | stalk test

Kill the environment

> stalk --kill test

Scripting from an application

Create a shared scripting environment (stand-alone process)

server = [[STServer launchedServerWithEnvrionmentName:@"test"];

... or connect to an existing one:

server = [[STServer serverWithIdentifier:@"test" host:@"localhost"];

Create a new conversation with the server

conversaton = [[STServer createConversaion];

Create a transcript object, just in case the server will produce an output

transcript = [[STSimpleTranscript transcript];
[conversation setTranscript:transcript];

Run a script in the shared environment:

[[conversation runScriptFromString:@"Transcript showLine:'Hello!'"];

The environment is a process that sits in the system until killed. Connection to the environment should be analogous to a connection to a database server. Executing StepTalk scripts is analogous to executing SQL commands.

The scripting environment process/server is something like a gateway from an user to the system (either whole system or user environment only). Is should persistant per session or there should be some mechanisms to store environment state and restore it later, after reboot for example.

What to do

What is required to implement it? Implementation of distant conversation and stpetalk server process. It will require small changes in the STEnvironment and addition of contexts. Engines should use contexts instead of an environment, so we can have a one Transcript per conversation, for example. Moreover, conversation should not return an object by default - different handling of script result should be implemented. I have already few random notes and code pieces, so if you are interested, please contact the author.