Mailing-List: contact websh-dev-help@tcl.apache.org; run by ezmlm
Precedence: bulk
To: Ronnie Brunner <ronnie.brunner@netcetera.ch>
Cc: websh-dev@tcl.apache.org
Subject: Re: TODO List - towards a release.
References: <87n0ytpfzo.fsf@dedasys.com> <20020207200834.C9642@netcetera.ch>
From: davidw@dedasys.com (David N. Welton)
Date: 08 Feb 2002 13:47:49 +0100
Message-ID: <876658uolm.fsf@dedasys.com>
Lines: 227
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Ronnie Brunner <ronnie@netcetera.ch> writes:

> here's my opinion on some of the issues:

Thanks!

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

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

This sounds ok to me, but will it provide enough flexibility in the
future?

... reading code ...

I suppose so.  It does it in a more Tcl'ish way, too, than adding even
more 'funny characters'.

This will slow things down just a bit, as loops like this:

    while (nextFromHashIterator(&iterator) != TCL_ERROR) {

	filter = (LogLevel *) valueOfCurrent(&iterator);
	if (doesPass(logLevel, filter) == TCL_OK)
	    return TCL_OK;
    }

Will have to check the whole list, to make sure there aren't any
'negators'.  Either that, or two lists...  We will also need a way to
represent these when we print out the list of filters.  '!' seems like
a logical candidate.  Might it be problematic though, that the output
of 'names' would not be parsable by 'logfilter add'?  I.e., you
couldn't cycle through the list and reuse it.

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

I don't think we can get much better than this.  We can hack cmdurlcfg
-scheme to return the default if it's not inserted, which should make
things work a little bit better.  Adding a second variable might also
make things a bit clearer, as you wouldn't have 'scheme' doing double
duty both as a config container and as something that gets data from
an external source.  One variable would contain the config options, or
null if there is none, the other would get filled in by the
environment, and the logic to pick and choose from the variables would
be in the actual url constructor.

> > * 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?

Ok, I could see this being an option, but it should not be on by
default.  I could see this shooting people in the foot really badly.

How about something along these lines:

proc docatch { code } {
        if { [catch [uplevel $code] err] } {
                if { [info exists defaultresponse] } {
                        puts "$defaultresponse" 
                } else {
                        puts "Houston, we have a problem: $errorInfo"
                }
        }
}

We could provide the option to wrap code in blocks like that, so that
the Tcl would be something like:

web::put { some raw HTML
 ...
}
docatch {
some tcl
code
}
web::put {
 more html
}

I don't know, though... if there is a page working incorrectly, I have
a suspicion that this is the sort of thing that would get noticed
after an hour of staring at the Tcl code and trying to figure out
what's wrong, and then noticing that someone had the clever idea to
set this option.  In my own code, I think I might use 'docatch'
explicitly, so that it's visible.

> 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

Ok, thanks.

> > * 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?

I don't have access to a windows box.  I wonder if there are any
publically available (sourceforge, for instance) for this sort of
experimentation?

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

Ok... I will try to update what I can, though, once the code is
frozen.

> > 3) Infrastructure

> > * Web site - what to do with it?  

[ ... private response ... ]

> > * Mailing lists.  They are archived on the web now, at apachelabs.org.
> >   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 apachelabs.org 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 apachelabs.org 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 "webmaster@apachelabs.org" ;-)

Ok.  I keep putting pressure on the apache guys to come up with
something that is strictly @apache.org, but I don't have root or
access to the mailing lists at a low level, so any kind of integrated
solution is difficult for me to create.  I could always set something
up that reads mail off the 'net on tcl.apache.org, but that's going to
be a hack, by its very nature.

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
     Personal: http://www.efn.org/~davidw/

---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org