You are viewing a plain text version of this content. The canonical link for it is here.
Posted to websh-dev@tcl.apache.org by "David N. Welton" <da...@dedasys.com> on 2002/04/10 15:49:33 UTC
web site
This is necessary for every page, but I've got most of the web site up
and running on my computer.
source [file join [file dirname [web::request SCRIPT_FILENAME]] websh.com.gen]
I've got things mostly squared away for www.apache.org, we now have a
role account there, which I will set you up with shortly.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> I have .ws3 files, set up, of course, with mod_websh. What I would
> like to do is to automate the loading of websh.com.gen for everything
> in a certain directory. I don't want that file loaded for every .ws3
> file I request, though, because it might interfere with other things I
> am testing.
Your .ws3 file are either code or templates. (meaning the .ws3 file
needs be eval'd or web::putxfile'd). The setup is a little different
in both cases. The easier case is code files:
wep::interpmap {file} {
# what needs to be passed to websh.com.gen
if {[match_websh.com.gen $file]} {
return /path/to/websh.com.gen
}
# default (all other files use their own class)
return $file
}
Note: for this to work, match_websh.com.gen is a proc that finds out
whether it is a request that must include websh.com.gen using some
pattern match or regex or similar and the websh.com.gen script must do
the following (at the end of the code)
# all stuff in websh.com.gen
# ...
web::include [web::config script]
# EOF
The setup for template files would be
wep::interpmap {file} {
# what needs to be passed to websh.com.gen
if {[match_websh.com.gen $file]} {
return /path/to/websh.com.gen
}
# default (all other files use their own class)
return /path/to/defaulthandler
}
where match_websh.com.gen is the same as above, but the websh.com.gen
script must look something like
# all stuff in websh.com.gen
# ...
web::putxfile [web::config script]
# EOF
and the defaulthandler script looks something like
# this is the default handler
web::putxfile [web::config script]
# EOF
You can actually mix the approach for each interpreter class you
define, but this could be confusing. A better solution would be to add
a second handler, such as a handler for .whtml (templates) and a
handler for .ws3 (scripts) using the following generic interpmap setup:
wep::interpmap {file} {
# scripts
if {[string match *.ws3 $file]} {
# they all have their own interp class
return $file
}
# templates (i.e. all *.whtml files)
return /path/to/defaulthandler
}
where the defaulthandler is essentialy a [web::putxfile [web::config script]]
command, just as above.
Ronnie
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> in the WebshConfig File, you still have to do this stuff manually:
> In your case, what you need to do is:
> Add a handler for websh (e.g. extension .ws3) and then you can
> (optionally) add a WebshConfig that overwrites web::interpmap.
> In you example: the WebshConfig file should throw an error, sionce
> web::config is unknown. Without that line, it'll generate a Server
> Error 500, since howdydoodee is not a valid interpreter class
> (i.e. no Websh3 file).
> What's the problem with interfereing with other stuff? Could it be
> that the current Websh handler is setup for *.html? Couldn't you add
> the handler in a <Directory> clause? This would route e.g. /websh/*
> files to mod_websh only.
> ... Sorry for not being very constructive here, I don't really know
> what you're trying to do ...
I have .ws3 files, set up, of course, with mod_websh. What I would
like to do is to automate the loading of websh.com.gen for everything
in a certain directory. I don't want that file loaded for every .ws3
file I request, though, because it might interfere with other things I
am testing.
Is that clearer? Sorry that the previous message wasn't.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> proc web::interpmap {file} {
> puts stderr [web::config script]
> return howdydoodee
> }
>
> doesn't seem to have any effect at all...
Well, I know! When I added the web::config stuff, I realized, that
in the main interpreter, we don't have the web::config command anyway
-> this stuff is mainly usefull to configure the actual applications
(since there you don't want to bother with changing absolute paths).
in the WebshConfig File, you still have to do this stuff manually: In
your case, what you need to do is:
Add a handler for websh (e.g. extension .ws3) and then you can
(optionally) add a WebshConfig that overwrites web::interpmap.
In you example: the WebshConfig file should throw an error, sionce
web::config is unknown. Without that line, it'll generate a Server
Error 500, since howdydoodee is not a valid interpreter class (i.e. no
Websh3 file).
...
What's the problem with interfereing with other stuff? Could it be
that the current Websh handler is setup for *.html? Couldn't you add
the handler in a <Directory> clause? This would route e.g. /websh/*
files to mod_websh only.
... Sorry for not being very constructive here, I don't really know what
you're trying to do ...
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> Can't be: either we talk about the mainInterp (which is already
> there) or we talk about the new interp (for the pool) in which we
> don't eval any code until all the init stuff is called (otherwise we
> would have a serious chicken & egg problem ;-)
> -> should be straight forward except for the [web::config
> interpclass] which is not available in mainInterp (which also makes
> sense)
Hrm... well, it's not working. web::config script works, I tested it
out in a page. Maybe I'm just not getting it...
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> Can't be: either we talk about the mainInterp (which is already
> there) or we talk about the new interp (for the pool) in which we
> don't eval any code until all the init stuff is called (otherwise we
> would have a serious chicken & egg problem ;-)
> -> should be straight forward except for the [web::config
> interpclass] which is not available in mainInterp (which also makes
> sense)
So what is the magic sequence to have a locally hosted tcl site that
doesn't interfere with other stuff? Everything seems to be working on
www.apache.org, I just need to duplicate it locally in order to clean
it up.
I'm a bit stumped/frustrated...
proc web::interpmap {file} {
puts stderr [web::config script]
return howdydoodee
}
doesn't seem to have any effect at all...
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by Ronnie Brunner <ro...@netcetera.ch>.
Can't be: either we talk about the mainInterp (which is already there)
or we talk about the new interp (for the pool) in which we don't eval
any code until all the init stuff is called (otherwise we would have a
serious chicken & egg problem ;-)
-> should be straight forward except for the [web::config interpclass]
which is not available in mainInterp (which also makes sense)
> But wait...
>
> Let me see if I have this right.
>
> web::config is created in
>
> cfg_Init, which is called by Websh_Init
>
> Websh_Init is called by createWebInterp
>
> createWebInterp is called by poolGetWebInterp, but at the end of the
> file - after the various interpmap things have already been called.
>
> Doesn't this leave us basically in the same place as before? I mean,
> it's not so bad if you have one web site per apache, but the idea of
> doing per-site include files is very convenient. Your interpmap
> script solves that problem nicely.
>
> Or am I missing something?
>
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> > > [web::config mod_websh] : conf->scriptName
> >
> > why such an odd name? How about web::config script to mirror 'info
> > script' in Tcl?
>
> sure: way better
>
> > > [web::config server_root] : ap_server_root
> > > [web::config interpclass] : id (interpool.c:320) (only within a request)
> > > [web::config doument_root] : ap_document_root(request_rec *r)
> >
> > > This seems the most straight forward approach to me.
> >
> > Ok, I will add these.
But wait...
Let me see if I have this right.
web::config is created in
cfg_Init, which is called by Websh_Init
Websh_Init is called by createWebInterp
createWebInterp is called by poolGetWebInterp, but at the end of the
file - after the various interpmap things have already been called.
Doesn't this leave us basically in the same place as before? I mean,
it's not so bad if you have one web site per apache, but the idea of
doing per-site include files is very convenient. Your interpmap
script solves that problem nicely.
Or am I missing something?
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> > [web::config mod_websh] : conf->scriptName
>
> why such an odd name? How about web::config script to mirror 'info
> script' in Tcl?
sure: way better
> > [web::config server_root] : ap_server_root
> > [web::config interpclass] : id (interpool.c:320) (only within a request)
> > [web::config doument_root] : ap_document_root(request_rec *r)
>
> > This seems the most straight forward approach to me.
>
> Ok, I will add these.
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> > > Have an accessor in web::config that sets up these vars at
> > > startup time for mod_websh and at request time for CGI (which is
> > > good enough there).
> > Accessing it through web::config isn't that hot, either, because
> > it's not really a global config option.
> Yes, but so are [web::config version] and [web::config copyright] ->
> we don't mess up anything that's not messed up yet anyway.
Ok.
> > > -> a common accessor in cfg.c with specific implementations in
> > > modwebsh_ap.c and modwebsh_cgi.c respectively should do the
> > > trick.
> > Maybe we could do something sneaky with iPtr->scriptFile in Tcl
> > itself? Too clever, probably...
> I would access stuff like
> [web::config mod_websh] : conf->scriptName
why such an odd name? How about web::config script to mirror 'info
script' in Tcl?
> [web::config server_root] : ap_server_root
> [web::config interpclass] : id (interpool.c:320) (only within a request)
> [web::config doument_root] : ap_document_root(request_rec *r)
> This seems the most straight forward approach to me.
Ok, I will add these.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web::config for mod_websh paths
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> > Have an accessor in web::config that sets up these vars at startup
> > time for mod_websh and at request time for CGI (which is good enough
> > there).
>
> Accessing it through web::config isn't that hot, either, because it's
> not really a global config option.
Yes, but so are [web::config version] and [web::config copyright] ->
we don't mess up anything that's not messed up yet anyway.
> > -> a common accessor in cfg.c with specific implementations in
> > modwebsh_ap.c and modwebsh_cgi.c respectively should do the trick.
>
> Maybe we could do something sneaky with iPtr->scriptFile in Tcl
> itself? Too clever, probably...
I would access stuff like
[web::config mod_websh] : conf->scriptName
[web::config server_root] : ap_server_root
[web::config interpclass] : id (interpool.c:320) (only within a request)
[web::config doument_root] : ap_document_root(request_rec *r)
This seems the most straight forward approach to me.
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web site
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> I just wanted to tell you this, because I had the exact same
> problem. My approach would be still the same as it was when we
> started this discussion:
> Have an accessor in web::config that sets up these vars at startup
> time for mod_websh and at request time for CGI (which is good enough
> there).
Accessing it through web::config isn't that hot, either, because it's
not really a global config option.
> -> a common accessor in cfg.c with specific implementations in
> modwebsh_ap.c and modwebsh_cgi.c respectively should do the trick.
> I'll be in school tomorrow and Saturday, so the earliest for me to
> look at it would be Sunday or Monday, but I could do it if you don't
> feel comfortable with it.
I feel comfortable with the code, but I want to make sure we get it
right.
Maybe we could do something sneaky with iPtr->scriptFile in Tcl
itself? Too clever, probably...
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web site
Posted by Ronnie Brunner <ro...@netcetera.ch>.
I just wanted to tell you this, because I had the exact same problem.
My approach would be still the same as it was when we started this
discussion:
Have an accessor in web::config that sets up these vars at startup
time for mod_websh and at request time for CGI (which is good enough
there).
-> a common accessor in cfg.c with specific implementations in
modwebsh_ap.c and modwebsh_cgi.c respectively should do the trick.
I'll be in scholl tomorrow and Saturday, so the earliest for me to
look at it would be Sunday or Monday, but I could do it if you don't
feel comfortable with it.
> Hrm... there is a problem, however. When interpmap is called,
> web::request isn't set up.
>
> I guess that leaves us back with the chdir problem. Maybe we need to
> immediately set up a variable... yuck:-/
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web site
Posted by "David N. Welton" <da...@dedasys.com>.
Hrm... there is a problem, however. When interpmap is called,
web::request isn't set up.
I guess that leaves us back with the chdir problem. Maybe we need to
immediately set up a variable... yuck:-/
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web site
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> > We will do this on tcl.apache.org, but the reason I didn't do
> > something similar immediately is this:
> > How to set up a testing environment that does not affect other
> > websh pages being run on my system. I got bit by this when
> > setting up the tcl.apache.org test site on my computer.
> The clean way to setup a server with different applications / setups
> for templates etc by just using multiple interpreter classes:
> proc web::interpmap {file} {
> if {[string match "*/myExamples/*" $file]} {
> # this is my own code for the examples
> return /path/to/script/for/examples/myScript
> }
> if {[string match "/path/to/special/app" $file]} {
> # an app with its own script code
> return /real/path/to/app/code
> }
> # default : the websh.com stuff
> return [file join [file dirname [web::request SCRIPT_FILENAME]] websh.com.gen]
> }
> Doesn't that help?
Yes, that can be made to work.
> > What I ended up doing is having a 'common.tcl' file that is loaded
> > at child init time on the live site, and loaded before each
> > request on my box.
> The "and loaded before each request" seems strange. I understand
> that in a page you explicitly want to test with new code it's easier
> to include the code in the file, because it's loaded (=eval'd) every
> time you request the page. But in all the other pages it shouldn't
> be there (where's all the fun of being faster with preloaded code
> ;-)
Well, it should be there, because it's the 'global' code that is
available to all pages within the site. Yes, it's 'slow' but since
it's just me using the computer, I don't really notice, and it's
faster than having to restart apache if I add something.
> > I'm not sure what the easiest/cleanest way to do this in Websh is,
> > though.
> Regarding what: testing or production?
On the production box, the mod_websh installation will be dedicated to
serving up the websh/ directory, and hopefully we won't be mucking
around too much with the code, so doing things statically is ok. The
testing box is the one that I was trying to find the best solution
for. The interpmap system above should do the trick.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web site
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> We will do this on tcl.apache.org, but the reason I didn't do
> something similar immediately is this:
>
> How to set up a testing environment that does not affect other websh
> pages being run on my system. I got bit by this when setting up the
> tcl.apache.org test site on my computer.
The clean way to setup a server with different applications / setups
for templates etc by just using multiple interpreter classes:
proc web::interpmap {file} {
if {[string match "*/myExamples/*" $file]} {
# this is my own code for the examples
return /path/to/script/for/examples/myScript
}
if {[string match "/path/to/special/app" $file]} {
# an app with its own script code
return /real/path/to/app/code
}
# default : the websh.com stuff
return [file join [file dirname [web::request SCRIPT_FILENAME]] websh.com.gen]
}
Doesn't that help?
> What I ended up doing is having a 'common.tcl' file that is loaded at
> child init time on the live site, and loaded before each request on my
> box.
The "and loaded before each request" seems strange. I understand that
in a page you explicitly want to test with new code it's easier to
include the code in the file, because it's loaded (=eval'd) every time
you request the page. But in all the other pages it shouldn't be there
(where's all the fun of being faster with preloaded code ;-)
> This way, it is also easier to change code there without having to
> restart things all the time.
Sure, as I said.
> I'm not sure what the easiest/cleanest way to do this in Websh is,
> though.
Regarding what: testing or production?
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web site
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> > This is necessary for every page, but I've got most of the web
> > site up and running on my computer.
> > source [file join [file dirname [web::request SCRIPT_FILENAME]] websh.com.gen]
> I don't see why this should be necessary: setting up mod_websh would
> look something like (in the WebshConfig file):
> proc web::interpmap {file} {
> return [file join [file dirname [web::request SCRIPT_FILENAME]] websh.com.gen]
> }
> web::interpclasscfg [file join [file dirname [web::request SCRIPT_FILENAME]] websh.com.gen] maxrequests 0
> This sets up one single interpreter class for all requests.
We will do this on tcl.apache.org, but the reason I didn't do
something similar immediately is this:
How to set up a testing environment that does not affect other websh
pages being run on my system. I got bit by this when setting up the
tcl.apache.org test site on my computer.
What I ended up doing is having a 'common.tcl' file that is loaded at
child init time on the live site, and loaded before each request on my
box.
This way, it is also easier to change code there without having to
restart things all the time.
I'm not sure what the easiest/cleanest way to do this in Websh is,
though.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web site
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> This is necessary for every page, but I've got most of the web site up
> and running on my computer.
>
> source [file join [file dirname [web::request SCRIPT_FILENAME]] websh.com.gen]
I don't see why this should be necessary: setting up mod_websh would
look something like (in the WebshConfig file):
proc web::interpmap {file} {
return [file join [file dirname [web::request SCRIPT_FILENAME]] websh.com.gen]
}
web::interpclasscfg [file join [file dirname [web::request SCRIPT_FILENAME]] websh.com.gen] maxrequests 0
This sets up one single interpreter class for all requests.
In websh.com.gen, all the code is in a web::initializer command,
except for the dispatch, which looks something like
web::putxfile [web::request SCRIPT_FILENAME]
or, if the file is not a template, but a script
source [web::request SCRIPT_FILENAME]
> I've got things mostly squared away for www.apache.org, we now have a
> role account there, which I will set you up with shortly.
Very cool.
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org