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

[Andreas K. <and...@ac...>]

> Andreas Kupries wrote:
>
> > Back to the issue of naming, you disliked 'comm::interp'.
> >
> Ignore this part -- I was not sure about it did hence I had thought that
> the name was not appropriate. However, "comm::interp" looks fine to me now.
>
> > 	Factored description of options into separate section
> > 	Updated the information about command results.
> > 		Impl. actually returns [list $comm $interp],
> > 		not $interp alone. Found that I need both
> > 		so that I can delete them when I am done with
> > 		them. [**]
> >
> >
> >
> > [**] I wonder if we should try to extend comm channels with client
> data instead.
> > Would allow us to stash the created interps with the channel, could be
> > configured to be deleted on channel destruction with some callback. Then we
> > would have only one result for the commands above.
> >
> Few related questions: what happens if the user happens to delete the
> interp? Will it destroy the comm channel or the comm channel will exist
> but it will throw an error on the remote side.

> Similarly what happens if the comm channel is destroyed? Will it delete
> the interp or is it the user's responsibility to do cleanup? I think
> that protocol, safe and safeBasic should do both: create as well as
> delete the interp and comm channel (even when exe_interp is provided for
> protocol). Only the comm::interp::link API should be allowed to work
> with previously created interpreters. This will keep the design clean
> and simple.

Deletion and cleanup are an area where you can shoot yourself into the foot
right now. Comm channel and interp are not linked to each other, none knows when
the other is deleted.

(1)	Delete the comm channel. The interpreter stays around.
	It does nothing as nobody is sending scripts to it anymore.
	A leak.

(2)	Delete the interp. The comm channel stays around. Any incoming
	script will be directed to the missing interp, causing an error
	to be thrown.

Without extending comm channels to know the interp I will have to wrap a snit
class around the comm/interp combination for proper cleanup.

However the multiple sugesstions to put this into 'comm' itself imply another
route, that the comm channel does know the interp and deletes it with itself ...
Looking over the comm manpage I find the work item

	Allow easier use of a slave interp for actual command execution
	(especially when operating in "not local" mode).

My work here could serve as that, with tighter integration and knowledge between
the various parts.
Create a comm channel and link it directly to an execution environment. Possibly
auto-created. Any
internally/auto created interp are deleted with the channel. Some restricted
visibility outside to allow for command definition and aliases ...


> As for protocol API, is it possible to specify additional arguments for
> aliased commands?

Yes.

> For example:
>
>     interp alias <src> foo <dst> bar <comm_id> arg2 ..
>
> can this be specified as:
>
>     comm::interp::protocol "foo {bar <comm_id> arg2 ..} foo2 bar2"

The cmd mapping argument to protocol is a dictionary. It maps command names to
_command_prefixes_. Which is what you want here.

Examples. The trivial use case is

	protocol {
		Lookup	lookup_name
		Register	register_name
		Unregister	unregister_name
		...
	}

Commands are mapped to commands.

The advanced use case is

	protocol [list \
		Lookup	[list $theobject lookup otherarg] \
		Register	[list $theobject register otherarg] \
		Unregister	[list $theobject unregister otherarg] \
	]

Commands are mapped to command prefixes containing additional arguments.


>
> What about callback hooks for comm channel? Are they executed in child
> interpreter or the main one. I guess since the comm object is linked to
> the child interpreter, everything will be evaluated in there.

No. The only hook which goes to the execution environment is the 'eval' hook.
I do not want the execution environment to do anything else than executing the
incoming scripts. Authentication, lost connection, and all the other
_management_
tasks are not things which I want the slave interpreter to see, or even
influence
in any way, shape, or form.



--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com
	Tel: +1 778-786-1122