tcllib-devel — Discussion of development for tcllib

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

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

> >> 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.
> >
> I am not sure that these are restricted to management tasks. For
> example: I use 'eval' hook for debugging

Debugging ... How ?

> and lost connection hook to
> perform clean up.

So you have a backend which keeps state based on where a request originated from
?

> If these are not executed in exe_interp context then I
> would not have access to global variables, etc for debugging, right?

It depends on what you are debugging, and how. Can you provide a trimmed example
?

Also note that the visions for 'protocol' vs 'safe' are very different. This can
affect our choices.

> The internal management tasks related to comm/interp functionality can be
> outside the execution environment but the user-registered hooks should
> be executed in the exe_interp context.

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.

For now I will go back to the drawing board and see how the functionality can be
integrated into the regular 'comm' package, i.e. what changes to syntax and
setup are needed, what internals I have access to with that, etc.

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

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

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

Andreas Kupries wrote:
> 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 ...
>   
Yes: that sounds right.
>> 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.
>   
I am not sure that these are restricted to management tasks. For
example: I use 'eval' hook for debugging and lost connection hook to
perform clean up. If these are not executed in exe_interp context then I
would not have access to global variables, etc for debugging, right? The
internal management tasks related to comm/interp functionality can be
outside the execution environment but the user-registered hooks should
be executed in the exe_interp context.

Hemang.

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

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

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

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.

As for protocol API, is it possible to specify additional arguments for
aliased commands? 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"


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.

Hemang.

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

[Michael S. <sc...@un...>]

dg...@ni... schrieb:
> Quoting Andreas Kupries <and...@ac...>:
>> I prefer the former actually, keep comm itself focused on the communication
>> aspects, and use the proposed package for the linkage to useful execution
>> environments.
> 
> I'm not a comm user, and I haven't carefully read all
> of these messages, but at arms length it sure looks like
> you're inventing a set of commands that would be good
> additions to the comm package itself, rather than another
> separate package.  I think that means I'm agreeing with
> Hemang.

I agree with Don and Hemang. Comm isn't really that much about
communications, its mainly about remote code execution with a bit of
communication thrown in, after all its a socket based replacement for
send...

You do not send plain messages, you send code.

Michael

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

[<dg...@ni...>]

Quoting Andreas Kupries <and...@ac...>:
> I prefer the former actually, keep comm itself focused on the communication
> aspects, and use the proposed package for the linkage to useful execution
> environments.

I'm not a comm user, and I haven't carefully read all
of these messages, but at arms length it sure looks like
you're inventing a set of commands that would be good
additions to the comm package itself, rather than another
separate package.  I think that means I'm agreeing with
Hemang.

That said, if more direct experience indicates this really
should be a separate package from "comm", then give it
a name separate from "comm" as well.  This nested namespace
stuff is anti-modular.

Just IMHO.

DGP

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

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

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

Not sure about that.

> Few minor comments: The name "exeip" looks confusing because of the "ip"
> string in it. How about calling it  "exe_interp" instead.

Done.

> Also, is this
> a separate package or part of current comm package --

Yes.

> do I have to call
> "package require comm::interp" to use it my script

Yes.

> or does it get
> automatically loaded when I do "package require comm".

No.

> I would prefer
> the latter.

I prefer the former actually, keep comm itself focused on the communication
aspects, and use the proposed package for the linkage to useful execution
environments.


Back to the issue of naming, you disliked 'comm::interp'.

Based on what the package does, or provides possible names could be

	comm::link		(does linkage of comm to interps)
and	comm::safe		(provides safe execution environments).


Below is an updated manpage in text format. Changes:

	Fixed the comm::comm typo
	exeip -> exe_interp
	ip -> interp
	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.

________________________________________________________________________________
____

comm::interp(n) 0.1 comm "Remote communication"

NAME
====

comm::interp - Linking communication channels to interpreters

SYNOPSIS
========

package require Tcl 8.4
package require comm ?4.3?
package require comm::interp ?0.1?

::comm::interp::protocol ?-option val...? cmds ?exe_interp?
::comm::interp::safeBasic ?-option val...?
::comm::interp::safe ?-option val...?
::comm::interp::link comm interp

DESCRIPTION
===========

The package *comm::interp* is a supplement to the package *comm* providing
facilities to easily link comm channels to (restricted) Tcl interpreters. By
default the scripts received by a comm channel are executed in the main
interpreter of the receiving process, making for a very insecure model of
execution. Something to be used only in a very secure and/or trusted
environment. For everyone else this package was written, allowing the easy
compartmentalization of execution, restriction to a safe environment, to
specific commands, etc. Together with the ability of *comm* to create multiple
channels, non-listening channels, local channels, etc. it is possible to handle
a very wide range of security requirements.

Note and remember that the communication channels provided by the package *comm*
are objects, i.e. commands, and not Tcl channels. whenever we talk about
channels we talk about objects, except where explicitly noted otherwise.

API
===

    ::comm::interp::protocol ?-option val...? cmds ?exe_interp?

        This command creates a new communication channel which understands
        exactly the commands listed as the keys of the dictionary cmds. The
        associated values are the actual commands executed in their lieu, in the
        existing interpreter exe_interp. This interpreter defaults to the
        current interpreter invoking the command. For any other interpreter it
        is the callers responsibility to create it.

        The command returns a 2-element list containing, in the given order, the
        fully qualified name of the communication channel, and the path of an
        internal interpreter used to connect comm channel and execution
        interpreter. This enables the caller to perform additional
        intializations of the internal interpreter, but is primarily done to
        allow proper deletion of both comm channel and interpreter when we are
        done. Regarding initializations, using an empty mapping for cmds for
        example will leave us with an empty interpreter to be initialized at
        will.

        The internal interpreter is set up such that it is empty of any and all
        commands, save for a set of aliases for the commands in the mapping
        cmds. As the script execution of the comm channel is directed into this
        interpreter this enforces the restriction of the protocol to the set of
        defined commands.

        For the options understood by this command see the section -> OPTIONS.

    ::comm::interp::safeBasic ?-option val...?

        This command creates a new communication channel which understands all
        the commands of a basic safe interpreter. The safe interpreter used for
        the execution of the received scripts is created by the command.

        The term _basic_ means that the created interpreter is the plain result
        of invoking interp create -safe.

        The command returns a 2-element list containing, in the given order, the
        fully qualified name of the communication channel, and the path of the
        created safe interpreter. This enables the caller to perform additional
        intializations of the safe interpreter, but is primarily done to allow
        proper deletion of both comm channel and interpreter when we are done.

        For the options understood by this command see the section -> OPTIONS.

    ::comm::interp::safe ?-option val...?

        This command a new communication channel which understands all the
        commands of a safe interpreter crated by the *safe* package of the Tcl
        core. The safe interpreter used for the execution of the received
        scripts is created by the command using the builtin command
        ::safe::interpCreate.

        The command returns a 2-element list containing, in the given order, the
        fully qualified name of the communication channel, and the path of the
        created safe interpreter. This enables the caller to perform additional
        intializations of the safe interpreter, but is primarily done to allow
        proper deletion of both comm channel and interpreter when we are done.

        For the options understood by this command see the section -> OPTIONS.

    ::comm::interp::link comm interp

        This command takes an existing communication channel comm as created by
        the package *comm*, and an existing interpreter interp and links them
        together. Afterward all scripts received by the channel are executed
        within the context of interp.

        This is the core functionality of this package, used by all preceding
        commands. It allows the most flexibility as both communication channel
        and the interpreter executing the received scripts can be created and
        configured at will. Thereas for the preceding commands the communication
        channel is created and restricted to be a listener, and the interpreters
        are various forms of safe environments, from the highly restricted
        protocol to the more open basic and extended safe interpreters.

OPTIONS
=======

All commands provided by this package taking any options understand the same set
of options.

They are -port, -local, and -silent, with the same meaning as explained in the
documentation for the package *comm*. The option -listen is not recognized, as
the new communication channels created by the commands (with the exception of
::comm::interp::link) are configured to always listen for incoming scripts, this
cannot be deactivated.

The options are always delegated to and processed by the new communication
channel.

SEE ALSO
========

comm

KEYWORDS
========

communication, ipc, message, remote communication, rpc, socket

COPYRIGHT
=========

Copyright (c) 2006 Andreas Kupries.


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

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.
>>
>>     
>
>   

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

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

> 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.
> 

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

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

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

Hi Andreas,

What is the main purpose of this library? If I understand correctly, it
seems like a wrapper utility to create the (safe) interpreter and a comm
channel within it. 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...?
}

And comm::interp::link is probably same as "interp transfer {}
<comm_chan> $i".

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.
However, on further thought, such a functionality (if developed) should
not be called interp 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. Also, for comm::interp::protocol API,
will it internally create <exeip> or are users expected to create it
before calling it?

BTW, ::comm::comm::interp looks too long. You may want to drop one
"comm" and call it ::comm::interp.

Hemang.

Andreas Kupries wrote:
> comm::interp - Remote communication
> Generated from file './modules/comm/interp.man' by tcllib/doctools with format
> 'text'
> comm::interp(n) 0.1 comm "Remote communication"
>
> NAME
> ====
>
> comm::interp - Linking communication channels to interpreters
>
> SYNOPSIS
> ========
>
> package require Tcl 8.4
> package require comm ?0.1?
>
> ::comm::comm::interp::protocol ?-option val...? cmds ?exeip?
> ::comm::comm::interp::safeBasic ?-option val...?
> ::comm::comm::interp::safe ?-option val...?
> ::comm::comm::interp::link comm ip
>
> DESCRIPTION
> ===========
>
> The package *comm::interp* is a supplement to the package *comm* providing
> facilities to easily link comm channels to Tcl interpreters. By default the
> scripts received by a comm channel are executed in the main interpreter of the
> receiving process, making for a very insecure model of execution. Something to
> be used only in a very secure and/or trusted environment. For everyone else this
> package was written, allowing the easy compartmentalization of execution,
> restriction to a safe environment, to specific commands, etc. Together with the
> ability of *comm* to create multiple channels, non-listening channels, local
> channels, etc. it is possible to handle a very wide range of security
> requirements.
>
> API
> ===
>
>     ::comm::comm::interp::protocol ?-option val...? cmds ?exeip?
>
>         This command creates a new communication channel which understands only
>         the commands listed as the keys of the dictionary cmds. The associated
>         values are the actual commands executed in their lieu, in the
>         interpreter exeip. This interpreter defaults to the main interpreter of
>         the thread this command is executed in.
>
>         To facilitate the above the command creates an internal interpreter
>         which aliases the commands to the execution interpreter on the one hand,
>         and is linked to the communication channel on the other hand.
>
>         The command returns the path of the internal interpreter to enable the
>         caller to perform additional intializations. Using an empty cmds mapping
>         for example leaves us with an empty interpreter to be initialized at
>         will.
>
>         The options and their values coming before the cmds mapping are
>         delegated to the new communication channel. The known options are -port,
>         -local, and -silent, with the same meaning as explained in the
>         documentation for the package *comm*. The option -listen is not
>         recognized, as the new communication channel will always listen for
>         incoming scripts, this cannot be deactivated.
>
>     ::comm::comm::interp::safeBasic ?-option val...?
>
>         This command a new communication channel which understands all the
>         commands of a basic safe interpreter. The safe interpreter used for the
>         execution of the received scripts is created by the command and returned
>         as its result, to enable the caller to perform additional initialization
>         at will.
>
>         The term _basic_ means that the created interpreter is the plain result
>         of invoking interp create -safe.
>
>         The options and their values are delegated to the new communication
>         channel. See comm::interp::protocol for the in-depth explanation of the
>         recognized options.
>
>     ::comm::comm::interp::safe ?-option val...?
>
>         This command a new communication channel which understands all the
>         commands of a safe interpreter crated by the *safe* package of the Tcl
>         core. The safe interpreter used for the execution of the received
>         scripts is created by the command using the command ::safe::interpCreate
>         and returned as its result, to enable the caller to perform additional
>         initialization at will.
>
>         The options and their values are delegated to the new communication
>         channel. See comm::interp::protocol for the in-depth explanation of the
>         recognized options.
>
>     ::comm::comm::interp::link comm ip
>
>         This command takes an existing communication channel/object comm, and an
>         existing interpreter ip and links them together. Afterward all scripts
>         received by the channel are executed within the interpreter ip.
>
>         This is the core functionality of this package, used by all preceding
>         commands. It allows the most flexibility as both communication channel
>         and executing interpreter can be created and configured at will. Thereas
>         for the preceding commands the communication channel is restricted to a
>         listener, and the interpreters are various forms of safe environments.
>
> SEE ALSO
> ========
>
> comm
>
> KEYWORDS
> ========
>
> communication, ipc, message, remote communication, rpc, socket
>
> COPYRIGHT
> =========
>
> Copyright (c) 2006 Andreas Kupries.
>
> --
> 	Andreas Kupries <and...@Ac...>
> 	Developer @ http://www.ActiveState.com
> 	Tel: +1 778-786-1122
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel
>   

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

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

comm::interp - Remote communication
Generated from file './modules/comm/interp.man' by tcllib/doctools with format
'text'
comm::interp(n) 0.1 comm "Remote communication"

NAME
====

comm::interp - Linking communication channels to interpreters

SYNOPSIS
========

package require Tcl 8.4
package require comm ?0.1?

::comm::comm::interp::protocol ?-option val...? cmds ?exeip?
::comm::comm::interp::safeBasic ?-option val...?
::comm::comm::interp::safe ?-option val...?
::comm::comm::interp::link comm ip

DESCRIPTION
===========

The package *comm::interp* is a supplement to the package *comm* providing
facilities to easily link comm channels to Tcl interpreters. By default the
scripts received by a comm channel are executed in the main interpreter of the
receiving process, making for a very insecure model of execution. Something to
be used only in a very secure and/or trusted environment. For everyone else this
package was written, allowing the easy compartmentalization of execution,
restriction to a safe environment, to specific commands, etc. Together with the
ability of *comm* to create multiple channels, non-listening channels, local
channels, etc. it is possible to handle a very wide range of security
requirements.

API
===

    ::comm::comm::interp::protocol ?-option val...? cmds ?exeip?

        This command creates a new communication channel which understands only
        the commands listed as the keys of the dictionary cmds. The associated
        values are the actual commands executed in their lieu, in the
        interpreter exeip. This interpreter defaults to the main interpreter of
        the thread this command is executed in.

        To facilitate the above the command creates an internal interpreter
        which aliases the commands to the execution interpreter on the one hand,
        and is linked to the communication channel on the other hand.

        The command returns the path of the internal interpreter to enable the
        caller to perform additional intializations. Using an empty cmds mapping
        for example leaves us with an empty interpreter to be initialized at
        will.

        The options and their values coming before the cmds mapping are
        delegated to the new communication channel. The known options are -port,
        -local, and -silent, with the same meaning as explained in the
        documentation for the package *comm*. The option -listen is not
        recognized, as the new communication channel will always listen for
        incoming scripts, this cannot be deactivated.

    ::comm::comm::interp::safeBasic ?-option val...?

        This command a new communication channel which understands all the
        commands of a basic safe interpreter. The safe interpreter used for the
        execution of the received scripts is created by the command and returned
        as its result, to enable the caller to perform additional initialization
        at will.

        The term _basic_ means that the created interpreter is the plain result
        of invoking interp create -safe.

        The options and their values are delegated to the new communication
        channel. See comm::interp::protocol for the in-depth explanation of the
        recognized options.

    ::comm::comm::interp::safe ?-option val...?

        This command a new communication channel which understands all the
        commands of a safe interpreter crated by the *safe* package of the Tcl
        core. The safe interpreter used for the execution of the received
        scripts is created by the command using the command ::safe::interpCreate
        and returned as its result, to enable the caller to perform additional
        initialization at will.

        The options and their values are delegated to the new communication
        channel. See comm::interp::protocol for the in-depth explanation of the
        recognized options.

    ::comm::comm::interp::link comm ip

        This command takes an existing communication channel/object comm, and an
        existing interpreter ip and links them together. Afterward all scripts
        received by the channel are executed within the interpreter ip.

        This is the core functionality of this package, used by all preceding
        commands. It allows the most flexibility as both communication channel
        and executing interpreter can be created and configured at will. Thereas
        for the preceding commands the communication channel is restricted to a
        listener, and the interpreters are various forms of safe environments.

SEE ALSO
========

comm

KEYWORDS
========

communication, ipc, message, remote communication, rpc, socket

COPYRIGHT
=========

Copyright (c) 2006 Andreas Kupries.

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

Re: [Tcllib-devel] Asking for comments on a ncgi patch (regexp ->string last/...)

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

Just looked at the comments in the bug report itself to see if anything had
accumulated which is important to the discussion here, and yes, there was:

*	Apparently this is a duplicate of #532774, and this report was
	fixed and closed in July 2nd, 2006.

*	This fix actually uses 'string first'.

And when looking at the code I find that parseMimeValue, while still using an
RE, uses one which is equivalent to 'string first' as well, non-greedy coded
explicitly through the RE itself. See below.

	if {[regexp -- {([^=]+)=(.+)} $sub match key val]} {
		...
	}

> Jeff is entirely right that the performance of regexp is somewhat
> unpredictable.  One of these years, I'm going to say, "very well, to
> perdition with my sanity!" and plunge into Henry's code.
>
> For CGI parsing, I believe it's the first = that's supposed to govern.
> The field name can easily be restricted to have no = in it, since
> it's in the form presented to the client.  The field value, on the other
> hand, is not controllable.
>
> Paradoxically, the regexp to recognize the leftmost = is much faster:
>
> % set x f[string repeat o 100]=ba[string repeat r 99]
> % time {regexp {^([^=]*)=(.*)$} $x -> name value} 10000
> 27.8222 microseconds per iteration
> % time {regexp {^(.*)=([^=]*)} $x -> name value} 10000
> 171.1232 microseconds per iteration
>
> The time in the slower regexp appears to be spent, by the way, in dealing
> with the consequences of the first pair of capturing brackets:
>
> % time {regexp {(?:.*)=(.*)} $x -> value} 10000
> 20.6424 microseconds per iteration
> % time {regexp {(.*)=(?:.*)} $x -> name} 10000
> 162.0929 microseconds per iteration
>
> My guess is that this common usage, in Henry's algorithm, leads to a
> state space explosion.  Much of the art of designing recognizers is
> the art of controlling such things in the common cases; regexp matching
> in general is PSPACE-complete, and our extended regexps are even worse.
> (If I recall correctly, the time for recognizing arbitrary regexps when
> counted repetition is allowed is not bounded by any tower of exponentials
> 2**(2**(2**...(2**n)...)))
>
> Kevin



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

Re: [Tcllib-devel] Asking for comments on a ncgi patch (regexp -> string last/...)

[<ke...@cr...>]

Jeff is entirely right that the performance of regexp is somewhat
unpredictable.  One of these years, I'm going to say, "very well, to
perdition with my sanity!" and plunge into Henry's code.

For CGI parsing, I believe it's the first = that's supposed to govern.
The field name can easily be restricted to have no = in it, since
it's in the form presented to the client.  The field value, on the other
hand, is not controllable.

Paradoxically, the regexp to recognize the leftmost = is much faster:

% set x f[string repeat o 100]=ba[string repeat r 99]
% time {regexp {^([^=]*)=(.*)$} $x -> name value} 10000
27.8222 microseconds per iteration
% time {regexp {^(.*)=([^=]*)} $x -> name value} 10000
171.1232 microseconds per iteration

The time in the slower regexp appears to be spent, by the way, in dealing 
with the consequences of the first pair of capturing brackets:

% time {regexp {(?:.*)=(.*)} $x -> value} 10000
20.6424 microseconds per iteration
% time {regexp {(.*)=(?:.*)} $x -> name} 10000
162.0929 microseconds per iteration

My guess is that this common usage, in Henry's algorithm, leads to a
state space explosion.  Much of the art of designing recognizers is
the art of controlling such things in the common cases; regexp matching
in general is PSPACE-complete, and our extended regexps are even worse.
(If I recall correctly, the time for recognizing arbitrary regexps when
counted repetition is allowed is not bounded by any tower of exponentials
2**(2**(2**...(2**n)...)))

Kevin


--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA

Re: [Tcllib-devel] Asking for comments on a ncgi patch (regexp -> string last/...)

[Jeff H. <je...@ac...>]

Arjen Markus wrote:
>> 	if {![regexp -- (.*)=(.*) $x dummy varname val]} {
>>          set varname anonymous
>>          set val $x
>>      }

> Shouldn't this be [string first]? That solution is better IMHO than the 
> [regex] one:
> Consider a string like:
>     x="y=z"

Correct or not, the regexp is string last because it is greedy.  I do 
believe that the example is correct for CGI, where the quoted string you 
  gave would not be legal (it would be encoded).

Jeff

Re: [Tcllib-devel] CVS tools in use outside of unix platforms ...

[Pat T. <pat...@us...>]

Andreas Kupries <aku...@sh...> writes:

>On unixoid platforms the main CVs client is 'cvs', easily executable from the 
>command line.
>
>What other clients or used on platforms like Windows, OSX, etc. ?
>
>Are any of these clients callable from the command line as well ?

You can get win32 native versions of cvs. A good option is to install
TortoiseCVS which is a exporer plugin. This also installs a cvs.exe in
the TortoiseCVS programs folder and this can be called just like unix
cvs.

-- 
Pat Thoyts                            http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97  10 CE 11 E6 04 E0 B9 DD

Re: [Tcllib-devel] Asking for comments on a ncgi patch (regexp -> string last/...)

[Arjen M. <arj...@wl...>]

Andreas Kupries wrote:

>Is the change below something the Tcl RE bytecompiler does automagically ?
>Could it be done ?
>
>
>https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1536890&group_id=12
>883
>
>	Category: ncgi
>	Submitted By: yahalom emet (yahalom)
>	Summary: regexp usage is inefficient and can hang
>
>	using regexp in ::ncgi::nvlist is slower that the
>	usage of string methods (although it looks better).
>	regexp also causes problems with bigger data which can
>	cause ncgi to get stuck (try running it on big post
>	data).
>
>	replace:
>
>	if {![regexp -- (.*)=(.*) $x dummy varname val]} {
>          set varname anonymous
>          set val $x
>      }
>
>
>	with:
>
>	set idx [string last "=" $x]
>	if {$idx==-1} {
>	   set varname anonymous
>	  set val $x
>	} else {
>	    set varname [string range $x 0 [expr {$idx-1}]]
>	    set val [string range $x [expr {$idx+1}] end]
>	}
>  
>
Shouldn't this be [string first]? That solution is better IMHO than the 
[regex] one:
Consider a string like:
    x="y=z"

(if that is not possible with post data, then I plead almost complete
ignorance of the details of CGI ...)

The regular expression would split this in: x="y and z" (as would 
[string last])

I doubt that is what you want, but then again, I am more than slightly 
ignorant
of the issues of CGI.

Regards,

Arjen

Re: [Tcllib-devel] Asking for comments on a ncgi patch (regexp ->string last/...)

[Jeff H. <je...@ac...>]

Andreas Kupries wrote:
> Is the change below something the Tcl RE bytecompiler does=20
> automagically ? Could it be done ?
>=20
>
https://sourceforge.net/tracker/?func=3Ddetail&atid=3D112883&aid=3D153689=
0&group_id=3D
12883
>=20
> 	using regexp in ::ncgi::nvlist is slower that the
> 	usage of string methods (although it looks better).
> 	regexp also causes problems with bigger data which can
> 	cause ncgi to get stuck (try running it on big post
> 	data).

There are a lot of cases where 'string' methods trump REs for speed.  =
This is
not a case that the bytecompiler tries to outsmart the user - it doesn't =
do
that for any capturing REs.  It would be nice if the RE handled this =
better.
I'm fairly certain that someone with strong determination and strong =
will (to
not go crazy ;) ) would find that the RE code is not efficient for many =
simple
cases.  Unfortunately I don't have the time for this review.  :(

Jeff

> 	replace:
>=20
> 	if {![regexp -- (.*)=3D(.*) $x dummy varname val]} {
>           set varname anonymous
>           set val $x
>       }
>=20
> 	with:
>=20
> 	set idx [string last "=3D" $x]
> 	if {$idx=3D=3D-1} {
> 	   set varname anonymous
> 	  set val $x
> 	} else {
> 	    set varname [string range $x 0 [expr {$idx-1}]]
> 	    set val [string range $x [expr {$idx+1}] end]
> 	}

[Tcllib-devel] Asking for comments on a ncgi patch (regexp -> string last/...)

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

Is the change below something the Tcl RE bytecompiler does automagically ?
Could it be done ?


https://sourceforge.net/tracker/?func=detail&atid=112883&aid=1536890&group_id=12
883

	Category: ncgi
	Submitted By: yahalom emet (yahalom)
	Summary: regexp usage is inefficient and can hang

	using regexp in ::ncgi::nvlist is slower that the
	usage of string methods (although it looks better).
	regexp also causes problems with bigger data which can
	cause ncgi to get stuck (try running it on big post
	data).

	replace:

	if {![regexp -- (.*)=(.*) $x dummy varname val]} {
          set varname anonymous
          set val $x
      }


	with:

	set idx [string last "=" $x]
	if {$idx==-1} {
	   set varname anonymous
	  set val $x
	} else {
	    set varname [string range $x 0 [expr {$idx-1}]]
	    set val [string range $x [expr {$idx+1}] end]
	}


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

Re: [Tcllib-devel] CVS tools in use outside of unix platforms ...

[Aaron F <ro...@fe...>]

For windows there are wincvs which is a thick client, or tortoisecvs 
which is an explorer shell extension. Also I think cygwin has a command 
line client.

--Aaron

Andreas Kupries wrote:
> On unixoid platforms the main CVs client is 'cvs', easily executable from the 
> command line.
> 
> What other clients or used on platforms like Windows, OSX, etc. ?
> 
> Are any of these clients callable from the command line as well ?
> 
> 

Re: [Tcllib-devel] CVS tools in use outside of unix platforms ...

[<Lar...@re...>]

L=F6rdagen den 1 juli 2006 kl 04.39 skrev Andreas Kupries:
>
> On unixoid platforms the main CVs client is 'cvs', easily executable =20=

> from the
> command line.
>
> What other clients or used on platforms like Windows, OSX, etc. ?

For most people on OSX who use CVS, I believe it too qualifies as a =20
unixoid platform, so the command-line 'cvs' is most likely the main one =20=

here too.

Nonetheless, there are other clients. The one I've used the most is =20
actually "MacCVS Pro" (http://www.maccvs.org/) as it has long been the =20=

default choice (see =20
http://alphatcl.sourceforge.net/wiki/pmwiki.php/CVS/=20
CvsUpdatesAlpha8XMacos) within the AlphaTcl project. I think there has =20=

been a shift towards using command-line cvs even there, however, =20
because MacCVS Pro sometimes had a nasty habit of creating (if memory =20=

serves) stale locks on files in the repository, for reasons noone has =20=

been quite able to track down. OTOH, there is at least one useful =20
feature in MacCVS Pro which I think is missing from the command-line =20
cvs, namely the ability to reencode files when checking them in or out.

> Are any of these clients callable from the command line as well ?

Well, they are certainly startable from the command line (although you =20=

may have to first locate the actual executable buried inside the =20
application bundle), but whether you can also usefully tell them to do =20=

anything that way is another matter. And even if you could, it's =20
probably not a good idea to run a CVS application the way one would run =20=

a CVS command-line tool, as applications tend to take a lot longer to =20=

start up.

But why should one restrict oneself to the command-line interface, when =20=

Tcl knows so many other forms of interprocess communication? In

http://alphatcl.cvs.sourceforge.net/alphatcl/Tcl/Packages/=20
vcCvs.tcl?revision=3D1.37&view=3Dmarkup

you may find the AlphaTcl code implementing interaction with various =20
CVS clients (older versions of this file may be a bit easier to analyse =20=

though, as the current one makes heavy use of xserv). Interaction with =20=

MacCVS and MacCVS Pro is based on communication using TclAE.

Lars Hellstr=F6m=

[Tcllib-devel] CVS tools in use outside of unix platforms ...

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

On unixoid platforms the main CVs client is 'cvs', easily executable from the 
command line.

What other clients or used on platforms like Windows, OSX, etc. ?

Are any of these clients callable from the command line as well ?


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

[Tcllib-devel] (proposed) Schedule for Tcllib 1.9 (Re: any thoughts on tcllib release?)

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

This mail has been cc'd to the conference organizers to get their
input on the proposed schedules (see below) as well.


Ok then, let us see how that is working out:

*	Have one month where the CVS is frozen except for bug work.

*	Have the RC (Release Candidate) ready one week before the
	GA (General Announcement). The CVS is fully frozen during that
	time except for absolute blockers. Any other work has to be
	either defered until after release, or put into a branch.

*	Make a GA the weekend before the conference begins.

With the conference held from Oct 9-13 this works out to the following
dates:

*	Frozen except for bugs from Friday Sep  1.
*	Release Candidate ready at  Friday Sep 29.
*	General Announcement    at  Friday Oct  6.
*	Conference		Mo-Fri     Oct 9-13. (*)

Which means that we have from now on 2 months for general work on
bugs, patches, new features until the work is restricted to bugs only.



However, I do not know how early the release has to be to get on the
conference CD. If the Friday before the conference is too short I
guess that we can move GA and RC one week back, for a full week
between GA and conference. That would work out to the following dates:

*	Frozen except for bugs from Friday Sep  1.
*	Release Candidate ready at  Friday Sep 22.
*	General Announcement    at  Friday Sep 29.
*	Conference		Mo-Fri     Oct 9-13. (*)




(*) Oh, a Friday the 13th :)

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

Re: [Tcllib-devel] any thoughts on tcllib release?

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

> I do expect to have some Snit updates done prior to the
> conference.

Oh, goody. Thanks.

>  it's just a question of getting the time together.

Good luck with that.

> Will

-- 
So long and have a nice weekend all,
	Andreas Kupries <aku...@sh...>
			<http://www.purl.org/NET/akupries/>
	Developer @	<http://www.activestate.com/>
-------------------------------------------------------------------------------

Re: [Tcllib-devel] any thoughts on tcllib release?

[Will D. <wi...@wj...>]

I do expect to have some Snit updates done prior to the
conference.  it's just a question of getting the time together.

Will

On Jun 29, 2006, at 10:06 AM, Andreas Kupries wrote:

>> Andreas Kupries wrote:
>>>> I was just over at http://www.tcl.tk/software/tcllib/ and was
>>>> looking at the release announcements. In 2000, 4 releases of Tcllib
>>>> occurred. In 2001, 2 releases, in 2002, 2 releases, in 2003, 1
>>>> release, in 2004, 2 releases, and in 2005, 1 release. Is there any
>>>> thought of how many Tcllib releases, and when, would occur during
>>>> 2006?
>>
>>> I definitely want to do one release just before the conference. I am
>>> not sure if we will have the time to make a release before that. If
>>> we want to do that we will likely have to start on it now.
>>
>> On the subject of bug fixes: I try to check from time to time if new
>> bugs or requests have turned up for the modules I feel responsible
>> for. But this is not a very systematic activity, I am afraid, and I
>> guess many developers do it like that.
>
>> A concerted action to clean up
>
> Such concerted actions usually happen just before a release.
>
>> the list of open bugs is a good incentive to be more pro-active.
>
>
>> On the subject of new modules: I have at least one module that I  
>> would
>> like to see in the next release - my diagram drawing stuff.
>
> This is more tklib, not tcllib. Still, tklib needs a new release as  
> well, right.
>
>> The code
>> is more or less ready, it needs to be cleaned up a bit and there  
>> needs
>> to be a proper manual, but that is doable within the current
>> timescale. (I am thinking of another one too, but that is not
>> available in easily distributable, electronic form yet, just as a
>> pattern of neuron bindings, or whatever is molecularly going on in my
>> head ;)).
>
> --
>         Andreas Kupries <and...@Ac...>
>         Developer @ http://www.ActiveState.com
>         Tel: +1 778-786-1122
>
>
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Tcllib-devel mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcllib-devel

------------------------------------------------------------------
        will -at- wjduquette.com      | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills

Re: [Tcllib-devel] any thoughts on tcllib release?

[Aaron F <ro...@fe...>]

I think it would be great to see regularly scheduled releases of tcllib. Tklib should always have a release (or be included) at the same time. Twice a year seems like a good number. At least it would give the impression that work is going on, since people are less likely to use what they consider abandoned code. And if a release is scheduled ahead of time then there is plenty of time to notify developers of feature freeze and time for bug fixes.

--Aaron

----- Original message -----
From: "Andreas Kupries" <and...@ac...>
To: "Arjen Markus" <arj...@wl...>, <tcl...@li...>
Sent: Thu, 29 Jun 2006 10:06:52 -0700
Subject: Re: [Tcllib-devel] any thoughts on tcllib release?

> >Andreas Kupries wrote:
> >>> I was just over at http://www.tcl.tk/software/tcllib/ and was
> >>> looking at the release announcements. In 2000, 4 releases of Tcllib
> >>> occurred. In 2001, 2 releases, in 2002, 2 releases, in 2003, 1
> >>> release, in 2004, 2 releases, and in 2005, 1 release. Is there any
> >>> thought of how many Tcllib releases, and when, would occur during
> >>> 2006?
> >
> >> I definitely want to do one release just before the conference. I am
> >> not sure if we will have the time to make a release before that. If
> >> we want to do that we will likely have to start on it now.
> >
> >On the subject of bug fixes: I try to check from time to time if new
> >bugs or requests have turned up for the modules I feel responsible
> >for. But this is not a very systematic activity, I am afraid, and I
> >guess many developers do it like that.
> 
> > A concerted action to clean up
> 
> Such concerted actions usually happen just before a release.
> 
> >the list of open bugs is a good incentive to be more pro-active.
> 
> 
> >On the subject of new modules: I have at least one module that I would
> >like to see in the next release - my diagram drawing stuff.
> 
> This is more tklib, not tcllib. Still, tklib needs a new release as well, right.
> 
> > The code
> >is more or less ready, it needs to be cleaned up a bit and there needs
> >to be a proper manual, but that is doable within the current
> >timescale. (I am thinking of another one too, but that is not
> >available in easily distributable, electronic form yet, just as a
> >pattern of neuron bindings, or whatever is molecularly going on in my
> >head ;)).
> 
> --
>         Andreas Kupries <and...@Ac...>
>         Developer @ http://www.ActiveState.com
>         Tel: +1 778-786-1122
>