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

[Hemang L. <hl...@ci...>]

Hi Andreas,

Thanks for the clarifications. Your original proposal looks good to me.
You should try to document its internal working somewhere.

Few minor comments: The name "exeip" looks confusing because of the "ip"
string in it. How about calling it  "exe_interp" instead. Also, is this
a separate package or part of current comm package -- do I have to call
"package require comm::interp" to use it my script or does it get
automatically loaded when I do "package require comm". I would prefer
the latter.

Hemang.
Andreas Kupries wrote:
>> Hi Andreas,
>>
>> What is the main purpose of this library?
>>     
>
> Convenience. I want simple commands to create the most common linkages
> of comm channels to restricted execution environments, instead of
> having to code the same things over and over for each service I choose
> to implement.
>
>   
>> If I understand correctly, it seems like a wrapper utility to create
>> the (safe) interpreter and a comm channel within it.
>>     
>
> Basically yes.
>
>   
>> For example:
>>     
>
>   
>> ::comm::comm::interp::safe ?-option val...?
>>
>> can be coded as:
>>
>> set i [interp create -safe]
>> $i eval {
>>     package require comm
>>     ::comm::comm new ?-option val...?
>> }
>>     
>
> That works really only for trusted interpreters. It won't work for the
> 'protocol' linkage at all, because the protocol interpreter has _only_
> the aliases, and nothing else, especially not 'comm' itself. It may
> work for the safe interpreter, with contortions.
>
> My implementation creates the comm channel in the current interpreter
> anmd then uses the 'comm event eval' hook to redirect execution into
> the restricted environment. That fully separates execution from
> communication and prevents the execution environment from being aware
> of how communication is done; it also has no way to tamper with the
> communication system, all influences will have to be approved through
> aliased commands.
>
>   
>> And comm::interp::link is probably same as "interp transfer {}
>> <comm_chan> $i".
>>     
>
> A communication channel as managed by 'comm' is an object, not a
> transferable socket. Although it internally uses sockets. That is why
> the argument is named 'comm', not 'chan'.
>
> So no, no transfer. See also the explanation above.
>
>   
>> At first, I thought this package provides safe interp restrictions on
>> the commands sent over the comm wire and that the filtered set of remote
>> commands received would still be executed in the main interpreter.
>>     
>
> It can be. If the 'exeip' for protocol is {}, aka current interpreter,
> and for the safe variants if the safe interp gets appropriate aliases.
>
>
>   
>> However, on further thought, such a functionality (if developed) should
>> not be called interp
>>     
>
> i.e. instead of comm::interp you would like a different name
> comm::NAME better, with NAME ?
>
>   
>> and your current approach of creating new interp
>> for each channel looks reasonable.
>>
>> For comm::interp::safe and safeBasic commands you may also want to
>> support optional ?exeip? argument.
>>     
>
> No. For 'protocol' I need it to immediately link the commands in the
> filtre interpreter to something sensible. In the 'safe*' links it is
> the callers responsibility to set aliases to somewhere else, if any.
>
> The 'protocol' stuff is intended for services with a fixed set of
> commands, and nothing else. Whereas 'safe*' stuff is more for
> implementing something like a remote console, or agent system, where
> some client sends some mobile code, i.e. agent, for execution and we
> want to contain it and its effects.
>
>
>   
>> Also, for comm::interp::protocol API,
>> will it internally create <exeip> or are users expected to create it
>> before calling it?
>>     
>
> The command expects to get an existing interpreter. That can be {},
> i.e. current, already existing, default. Or one newly created by the
> caller of 'protocol'.
>
>
>   
>> BTW, ::comm::comm::interp looks too long. You may want to drop one
>> "comm" and call it ::comm::interp.
>>     
>
> "comm::comm::interp" is a typo. It should have been "comm::interp".
>
>   
>> Hemang.
>>
>>     
>
>