Re: [Tcllib-devel] A proposed new package ... Asking for comments.

[Andreas K. <aku...@sh...>]

> Andreas Kupries wrote:
> >
> > I am still not convinced. Maybe we have simply too different visions for what we
> > want to do with this.
> >
> > When I wrote these commands I wanted to have convenient setup functionality
> > specifically for and only for the eval hook. The other hooks simply did not
> > enter the picture, they were out of scope. To put them into scope I need a very
> > clear picture/vision on how they are used in such a situation.

[explanation and examples snipped -- Thank you for them]

I have now redone my proposal under the assumption that it becomes new
features of comm itself ... This collapsed and removed most of the
stuff in the original proposal. 

The new proposal basically provides communication channels with an
option to set an interpreter for execution. This is the link command
of the original proposal. The implementations of safeBasic and safe
commands of the original become so trivial in the new scheme that
providing special commands for them is not worthwhile. I.e.

       comm::comm new FOO -interp [interp create -safe]
or     comm::comm new FOO -interp [safe::interpCreate]

The protocol command of the original proposal also reduces to 'create
an empty interpreter and set aliases into it'. For the case of linking
the aliases to a second interpreter 'interp alias' is still the best
way of doing it, reducing this further to 'create an empty interp'. We
can do a command for that, this is however quite general and unrelated
to comm. Anybody with an idea where to place such command ? (Maybe a
package "interp" ?)

Still, the use case of linking the execution interpreter to a snit
object may warrant a command to make this easier. Create empty interp,
link to method in the object, specified through a list of names. Or a
snit type ... snit::comm-listener, snit::comm, snit::listener, ... ?


Here is the documentation of the new features of comm. Note that there
is a second option to control the execution of event/hook scripts, for Hemang

_______________________________________________________________________________
--- comm.man.orig	2005-10-03 21:03:19.000000000 -0700
+++ comm.man	2006-08-11 23:16:24.000000000 -0700
@@ -185,6 +185,9 @@
 [lst_item "[option -local]  [opt [arg 0|1]]"]
 [lst_item "[option -port]   [opt [arg port]]"]
 [lst_item "[option -silent] [opt [arg 0|1]]"]
+
+[lst_item "[option -interp]   [opt [arg interpreter]]"]
+[lst_item "[option -ipevents] [opt [arg eventlist]]"]
 [list_end]
 
 [para]
@@ -198,11 +201,12 @@
 
 [para]
 
-When [cmd config] changes the parameters of an existing channel, it
-closes and reopens the listening socket.  An automatically assigned
-channel [emph id] will change when this happens.  Recycling the socket
-is done by invoking [cmd {::comm::comm abort}], which causes all
-active sends to terminate.
+When [cmd config] changes the parameters of an existing channel (with
+the exception of [option -interp] and [option -ipevents]), it closes
+and reopens the listening socket. An automatically assigned channel
+[emph id] will change when this happens. Recycling the socket is done
+by invoking [cmd {::comm::comm abort}], which causes all active sends
+to terminate.
 
 [subsection {ID/PORT ASSIGNMENTS}]
 [para]
@@ -238,6 +242,51 @@
 attempts where the protocol negotiation phase failed, instead of
 throwing an error.
 
+[subsection {EXECUTION ENVIRONMENT}]
+
+A communication channel in its default configuration will use the
+current interpreter for the execution of all received scripts, and of
+the event scripts associated with the various hooks.
+
+[para]
+
+This isecure setup can be changed by the user via the two options
+[option -interp], and [option -ipevents].
+
+[para]
+
+When [option -interp] is set all received scripts are executed in the
+slave interpreter specified as the value of the option. This
+interpreter is expected to exist before configuration. I.e. it is the
+responsibility of the user to create it. However afterward the
+communication channel takes ownership of this interpreter, and will
+destroy it when the communication channel is destroyed.
+
+Note that reconfiguration of the communication channel to either a
+different interpreter or the empty string will release the ownership
+[emph without] destroying the previously configured interpreter.  The
+empty string has a special meaning, it restores the default behaviour
+of executing received scripts in the current interpreter.
+
+[para]
+
+[emph {Also of note}] is that replies and callbacks (a special form of
+reply) are [emph not] considered as received scripts. They are
+trusted, part of the internal machinery of comm, and therefore always
+executed in the current interpreter.
+
+[para]
+
+Even if an interpreter has been configured as the execution
+environment for received scripts the event scripts associated with the
+various hooks will by default still be executed in the current
+interpreter. To change this use the option [option -ipevents] to
+declare a list of the events whose scripts should be executed in the
+declared interpreter as well. The contents of this option are ignored
+if the communication channel is configured to execute received scripts
+in the current interpreter.
+
+
 [subsection {REMOTE INTERPRETERS}]
 [para]
 
_______________________________________________________________________________

-- 
So long,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------