From owner-freebsd-arch@FreeBSD.ORG Fri Aug 1 17:59:15 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7048177C; Fri, 1 Aug 2014 17:59:15 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C7F9208C; Fri, 1 Aug 2014 17:59:14 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s71Hx6pC050606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2014 10:59:07 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s71Hx63m050605; Fri, 1 Aug 2014 10:59:06 -0700 (PDT) (envelope-from jmg) Date: Fri, 1 Aug 2014 10:59:06 -0700 From: John-Mark Gurney To: Marcel Moolenaar Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <20140801175906.GA50495@funkthat.com> Mail-Followup-To: Marcel Moolenaar , Phil Shafer , "Simon J. Gerraty" , Poul-Henning Kamp , arch@freebsd.org, Marcel Moolenaar References: <201408011550.s71FoiQo003612@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 01 Aug 2014 10:59:07 -0700 (PDT) Cc: arch@freebsd.org, Poul-Henning Kamp , Marcel Moolenaar , Phil Shafer , "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:59:15 -0000 Marcel Moolenaar wrote this message on Fri, Aug 01, 2014 at 09:25 -0700: > On Aug 1, 2014, at 8:50 AM, Phil Shafer wrote: > > > "Simon J. Gerraty" writes: > >> Of course I wouldn't be surprised if the lib already handles all that ;-) > > > > No, I can't manufacture memory on the fly ;^) > > > > Hmmm... I could have an emergency mode where I stop trying to buffer > > and churn out a series of small write() calls to send close tags. > > Or perhaps just punting and refusing to write more once ENOMEM is > > seen is the right thing. Seeing broken output is better than limping > > along with output that looks right but isn't. > > But broken output can have nasty side-effects due to > parsers tripping over. What we try to prevent here > (limping along) can very easily be introduced by us > by emitting something that trips over parsers. We > merely pushed the limp-along problem downstream from > us. The just pushed the error handling further down stream... I'd trust a parse error more than someone handling all the odd edge cases of missing tags, or even failure to parse the error tag... IFF we have a proper DTD/spec that includes an error tag can we even think of making an error document parsable when an error occured... Either choice we make pushes the error handling down stream... One case, it's the parser, the other case it's the consumer of the parser, but in both cases the downstream HAS to properly handle the error however it is signaled... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."