RFC: StepTalk semi-persistent shared environment(s)

[Stefan Urbanek]

Hi,

As I have access to the interned again, I would like to share some news.
I have implemented a prototype of StepTalk semi-persistent shared
environment.

** Contents of this email

- About semi-persistent shared environment
- Documentation and sources
- Example
- Questions

** About semi-persistent shared environment

What is a semi-persistent shared environment? It is a scripting
environment that resides in a stand-alone process and therefore is, from
application's or tool's point of view, persistent for a whole computer
session. That means that the environment exists until the process is
terminated. The environment can be shared by more applications or can be
used by a several subsequent launches of a tool.

** Documentation and sources

More about the environment can be learnt from the following document:

http://stefan.agentfarms.net/Download/GNUstep/Documents/StepTalk-remote.pdf

The changes are not yet commited to the CVS, however they are available
here:

http://stefan.agentfarms.net/Download/GNUstep/Prototypes/StepTalk-20050819.tar.gz

** StepTalk changes

Notable changes (for more information see ChangeLogs):
- new class STDistantConversation for conversations with distant objects
was added
- STConversation does not return value on script execution, the value
has to be get by separate pair of method calls, one for getting the
value by reference and the other to get the value by copy. for local
conversations both methods are the same.
- new tool Tools/stenvironment for semi-persistent scripting
environments was created, try: stenvironment --help
- mechanism for connecting to the distant environments was added to the
tools stexec and stshell
- Tools/stalk was removed as it was definitely obsoleted by the new
distant conversation functionality

Other non-related changes:
- Tools/stexec: added reading from stdin; reflect library changes
- depreciated methods were removed from STEnvironment

** Example

Example is attached as distant.st. Usage of the script:

        1. run: stenvironment -name test
        2. run: stexec distant.st
        3. repeat step 2. as many times as you like

Step 1. creates a shared semi-persistent scripting environment. Step 2.
executes this script that connects to the environment and executes some
code there. The script contains comments and I think that it is quite
understandable. However, if something is not clear then ask me.

** Questions

Following are several questions regarding the new addition to the
StepTalk. I would like to hear your opinion.

1. naming questions

- is the name STDistantConversation right?
- interpretScript:inEnvironment or interpretScript:environment?
- methodFromSource:forReceiver:inContext: or
methodFromSource:receiver:context:

2. reference or copy?

- what should be default: returning result by reference or by copy? that
is, the method -result should return reference or copy? if reference,
then there would be following pair:
   - result
   - resultByCopy (or copyOfResult?)
otherwise there would be following pair:
   - result
   - resultByReference
Or - resulByCopy:(BOOL)flag?

3. Passing object there and back

- How to pass objects to the distant environment?  Problem is simple:
what if I pass an object by reference to the environment and I will die?
One suggestion is, that user will be allowed to pass a dictionary bycopy
to the conversation on the environment process side with some simple
variables only. However, that should be only a temporary solution before
a more complex solution would be found.

- How to get objects from the distant environment? At the moment, there
is only one way how to get them and that is to execute a script that
returns required object and get it using - result (either by reference
or by copy). Thing is, that at the moment context of distant
conversation is not available. When it would be available, then what
methods should be provided and with what restrictions? (see STContext.h
and STEnvironment.h)

3. Should be creation of the distant environment (launching new
stenvironment process) included in the framework? If yes, then how?
Separate class? *Manager or *Server or something else?

4. What is the best way to terminate a distributed objects server?

5. How would you expect termination of the environment process to be
handled?
- Can it be allowed from a script or programatically from conversation
only?
- If from script, then how? 'Environment close' or 'Environment
suicide' (analogy to external KILL signal, that is, KILL to self)?

** End

Any feedback is welcome. If you have questions, comments, patches,
suggestions then do not hesitate to contact me.

Enjoy,

Stefan Urbanek

p.s.: I'll process other emails soon.
-- 
http://stefan.agentfarms.net

First they ignore you, then they laugh at you, then they fight you, then
you win.
- Mahatma Gandhi

distant.st
Description: Text document