Return-Path: Mailing-List: contact websh-dev-help@tcl.apache.org; run by ezmlm Delivered-To: mailing list websh-dev@tcl.apache.org Received: (qmail 16392 invoked from network); 28 Dec 2001 09:56:37 -0000 Received: from netcetera-139.netcetera.ch (HELO netcetera.ch) (193.192.248.139) by daedalus.apache.org with SMTP; 28 Dec 2001 09:56:37 -0000 Received: from ska.netcetera.ch (ska [193.192.248.249]) by (8.9.3/8.7.3) with ESMTP id KAA13000; Fri, 28 Dec 2001 10:56:33 +0100 (MET) Received: by ska.netcetera.ch (8.9.3) id KAA20463; Fri, 28 Dec 2001 10:56:32 +0100 (MET) Date: Fri, 28 Dec 2001 10:56:32 +0100 From: Ronnie Brunner To: "David N. Welton" Cc: websh-dev@tcl.apache.org Subject: Re: putx of empty string before first brace does not send headers Message-ID: <20011228105632.C20356@netcetera.ch> Reply-To: Ronnie Brunner References: <871yhiyn0p.fsf@dedasys.com> <20011226180631.B18536@netcetera.ch> <87zo45x4zu.fsf@dedasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87zo45x4zu.fsf@dedasys.com>; from davidw@dedasys.com on Wed, Dec 26, 2001 at 06:31:33PM +0100 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > > Does that really solve the problem of "coding around things"? Would > > you always buffer the first non-Tcl junk? Buffering as such requires > > some "coding around things", or am I wrong? > > Yes, but the code that results is less ugly, in my opinion, because > you end up using more standard Tcl things rather than doing it at the > parser level. I still have a problem with your "buffering" solution: - changing the buffer size and hoping that it is sufficiently large to hold the first block is too shaky in my opinion. btw I'm not sure whether Tcl actually has to fill the buffer before it flushes anything. (The man page just says: "Tcl will normally delay output until the buffer is full or the channel is closed." This sounds too wage for my taste to be reliable.) - Doesn't the CGI setup of websh make your solution very ugly? Modifying the headers after something is written two the (buffered) output requires reading back the buffer (w/o flushing), writing the headers and rewriting the previous buffer content. I can't imaginge how you want to do this in a not-ugly fashion. Ronnie ------------------------------------------------------------------------ Ronnie Brunner ronnie.brunner@netcetera.ch Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75