From owner-freebsd-arch@FreeBSD.ORG Fri Aug 1 16:25:43 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CABA2A1; Fri, 1 Aug 2014 16:25:43 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19F8825DF; Fri, 1 Aug 2014 16:25:42 +0000 (UTC) Received: from [192.168.2.25] (atc.xcllnt.net [50.0.150.213]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id s71GPYMb001144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2014 09:25:35 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_134438E9-D07D-4C1D-A44D-D177AC448546"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML From: Marcel Moolenaar In-Reply-To: <201408011550.s71FoiQo003612@idle.juniper.net> Date: Fri, 1 Aug 2014 09:25:34 -0700 Message-Id: References: <201408011550.s71FoiQo003612@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1878.6) Cc: arch@freebsd.org, Poul-Henning Kamp , Marcel Moolenaar , John-Mark Gurney , "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 16:25:43 -0000 --Apple-Mail=_134438E9-D07D-4C1D-A44D-D177AC448546 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii 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. To get a reliable chain from producer to consumer, it may be best to have correct structure at all times and tackle the limp-along problem with constructs within that structure to signal that the data within that structure is complete and/or sound. For example: if stdout and stderr are separate tags in the XML output, then a third tag, say status, can be added to indicate that the stdout and stderr tags are accurate/complete. Or something along those lines. To me machine parseable output is only that if it is parseable at all times. Machines suck at interpreting their input when it suddenly stops being parseable. The best you can expect is garbage in, garbage out. While it sounds easy to just reject the entire input in that case (i.e. when some tool emits broken output), the fact that we may opt to just abort the output based on the fact that we may have emitted bits of it and can't undo it should be treated as an indication that pretty much any program is really behaving very similar and act upon it's input right away and not wait until it's seen the end and likes what it has seen. Rejecting the entire input when the structure is broken is just not something to bank on. $0.02 -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_134438E9-D07D-4C1D-A44D-D177AC448546 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPbv34ACgkQpgWlLWHuifbtVACfRe8mobKENTajml41cAx0Y4Kk EzgAni0s1bjetR4Uu/gtrhpMoLQx/5Dy =DH8K -----END PGP SIGNATURE----- --Apple-Mail=_134438E9-D07D-4C1D-A44D-D177AC448546--