tcl-websh-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronnie Brunner <>
Subject Re: TODO List - towards a release.
Date Thu, 07 Feb 2002 19:08:34 GMT

here's my opinion on some of the issues:

> Open Issues:
> * 4714: extend log file options to be able to log all but one log
>   level.  
>   Question: does it make sense to extend the functionality to
>   accomplish what syslog does?

wouldn't the simplest approach be to add a subcommand "exlude" to

	web::logfilter exclude some.debug

This would be a global filter that just excludes messages of the
specified types. (In contrast to the add subcommand: these levels
can't be added with later calls to "web::logfilter add".) 

> * 4720, 5043: using raw 'env' array not correct way of doing things.
>   Possible replacement suggested, awaiting comments because it is not
>   %100 backwards compability with previous functionality.
>         by default, urlData->scheme is not filled in, leaving it as a
>         config option, which does fill it in.
>         At 'runtime' (when cmdurl is run), it then either fills it in
>         with 1) the config option (takes precedence) 2) https, if
>         that's found amongst the environmental variables, or 3) the
>         default.
>         The problem is that  lappend res [web::cmdurlcfg -scheme]
>         doesn't work anymore, as things are filled in at runtime.

still not happy, but no cool idea yet. I'll sleep over it again.

> * 4724: (web::putxfile: eval all file even in case of an error in one
>   block).  
>   I don't have a good explanation of why a file running broken code
>   should continue when there are problems.  There has been some
>   discussion of this issue lately on comp.lang.tcl, and it appears as
>   if it's difficult to accomplish, and possibly buggy.  
>   Since we control the environment, I would suggest that if there are
>   non-fatal problems, we reflect that in our Tcl usage (catch), rather
>   than ignoring all errors and attempting to continue at all costs.

daydreaming: if we could somehow set a handler for errors in blocks it
would be easier to deliver valid HTML responses even if errors in code
blocks occcur: even if "eval"ing the block fails, the surrounding HTML
code will be output and instead of the result of the block, we'd get
whatever the error handler returns/puts out:

imagine a file count.html containing 

	"<html><body>at least {counter} page visits</body></html>"

if counter fails, now we get

	"<html><body>at least "

which is not cool, because it breaks the file structure. If we don't
do anything, just continue to eval the rest of the file, we would get:

	"<html><body>at least  page visits</body></html>"

which is sub-optimal as well.

If we could have an error handler for failing blocks, we could do
something like

	[web::putxfile count.html -onerror {web::put "some"} ]

which would produce

	"<html><body>at least some page visits</body></html>"

ok, I admit: much ado about not such a great idea, but my point is: it
sometimes makes more sense to just "drop" a broken block and continue
with evaluation that just stop "eval"ing. -> Maybe this could be an
option? [web::putxfile <channel> file <-continue>] or something?

sThe countersuppose the file

> * 4729: catch used with web::dispatch.  
>   The provided example isn't something reproducable.  Unclear what the
>   exact problem is, and am hoping that a test case might be made
>   available which illustrates the problem.

I'll ask Simon whether he can provide a better example for illustration

> * 4740: build system.  What remains to be done?
>   - RPM's and, hopefully, Debian packages.

How about windows? Did anyone lately try to build a windows version?

> 2) Documentation
> * The documentation needs to be brought up-to-date to reflect the
>   current state of affairs, new commands, functionality, and so on.  A
>   build system is also necessary in order to be able to create
>   multiple outputs (printed, web, etc...) from the sources.

definitly: I think that's something we can address when you're in
Zurich, in two+ weeks. IMHO this is one of the crucial opints for a
good release: having a MATCHING documentation of the implemented
features (we really suffer from the current status).

> 3) Infrastructure
> * Web site - what to do with it?  
>   There are several options for hosting.
>   - Leave things as they are, and just link from
>  Speaking from my Apache chair, I don't
>     particularly like this, as I would like for WebSH to be a part of
>     the Apache fold.
>   - Move things over to in some fashion.  I have root
>     on this machine, so we can do whatever needs be with it to make
>     things work.
>   As far as design issues go, the current site is very nice, and the
>   only immediate change might be some more link exchanges between
> and  Shall we do this immediately, or wait
>   for the release and have a sort of "big bang"?  This touches on
>   marketing strategy.

I would be happy to move the whole site to (We could
keep running with an index page linking to or something -> o.k. with me. 

One problem however: the site is currently created with a batch job
that consistently creates the pages (navigation and stuff) and we
should think about how we should migrate this. My favorite solution
would be to actually have a dynamic site driven by mod_websh! (this
needs some thoughts first. Another issue for our later Feb meeting?

As for the going online, I opt for the big bang: publish the site when
we have the release to really get an impact and show something: a release.

> * Mailing lists.  They are archived on the web now, at
>   I am still haranguing the Apache folks to try and square something
>   away so that we have archives on *our* machines under our control.
>   However, the guy behind is quite helpful and
>   responsive, for the moment.  If you have any comments about the
>   archives as they stand now, I would be happy to pass them along.

The is simple but usefull: since we don't really have
much more to offer at this time I'd say: let's keep it as it is and
say thanx to "" ;-)

> 4) Timeline

My answers to the previous questions reflect quite the same opinion
about the timeline: so no further suggestions from my side

> My proposal for the timeline is as follows:
> Step 1: source code work, with goal of freezing code for our meeting
> towards the end of February.
> Step 2: Update documentation to reflect current sources.
> Step 3: Discuss infrastructure and other outstanding issues at
> meeting, and agree on a plan.
> Step 4: Resolve any outstanding issues or problems.
> Step 5: Release, including 'marketing' - press release on Apache
>         release list, open source sites (lwn, slashdot, etc...).

Ronnie Brunner                     
Netcetera AG, 8040 Zuerich    phone +41 1 247 79 79 Fax: +41 1 247 70 75

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message