Date: Fri, 1 Aug 2014 09:25:34 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Phil Shafer <phil@juniper.net> Cc: arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Marcel Moolenaar <marcel@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <EDD200F3-9D35-4A8D-BE3B-40B19C61CD88@xcllnt.net> In-Reply-To: <201408011550.s71FoiQo003612@idle.juniper.net> References: <201408011550.s71FoiQo003612@idle.juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <phil@juniper.net> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EDD200F3-9D35-4A8D-BE3B-40B19C61CD88>