Date: Thu, 31 Jul 2014 14:33:03 -0700 From: Jordan Hubbard <jkh@turbofuzz.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: sjg@freebsd.org, arch@freebsd.org, marcel@freebsd.org, Phil Shafer <phil@juniper.net> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <92A1A2E4-6154-460F-8682-A39F0EB6198C@turbofuzz.com> In-Reply-To: <20140731210937.GV43962@funkthat.com> References: <20140731175547.GO43962@funkthat.com> <201407311839.s6VIdlMK096434@idle.juniper.net> <20140731210937.GV43962@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jul 31, 2014, at 2:09 PM, John-Mark Gurney <jmg@funkthat.com> wrote: > > Well, from my understanding there can't be a "locale" that is UTF-8 > as a locale contains more than just character encoding... It also > includes month/day names, sorting, etc... I think you can get a > C locale (the default) w/ UTF-8 by setting the correct environment > variables, but I don't know them well enough to say... Should we add > a locale that does this? There is UTF-8 in /usr/share/locale, but if > you set LANG to it, things don't work.. en_US.UTF-8 From owner-freebsd-arch@FreeBSD.ORG Thu Jul 31 21:36:45 2014 Return-Path: <owner-freebsd-arch@FreeBSD.ORG> 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 C61EFA40; Thu, 31 Jul 2014 21:36:45 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8B16B2ADD; Thu, 31 Jul 2014 21:36:45 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 5FCC71578; Thu, 31 Jul 2014 21:36:44 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s6VLahku058666; Thu, 31 Jul 2014 21:36:43 GMT (envelope-from phk@phk.freebsd.dk) To: Phil Shafer <phil@juniper.net> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML In-reply-to: <201407312130.s6VLUFSP097778@idle.juniper.net> From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> References: <201407312130.s6VLUFSP097778@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <58664.1406842603.1@critter.freebsd.dk> Date: Thu, 31 Jul 2014 21:36:43 +0000 Message-ID: <58665.1406842603@critter.freebsd.dk> Cc: sjg@freebsd.org, arch@freebsd.org, John-Mark Gurney <jmg@funkthat.com>, marcel@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>; List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 31 Jul 2014 21:36:45 -0000 -------- In message <201407312130.s6VLUFSP097778@idle.juniper.net>, Phil Shafer writes: >Poul-Henning Kamp writes: >>Can I point discreetely at sbuf(3)'s accumulative error handling >>and suggest that libxo does something similar ? That way applications >>only need to check for errors once, rather than after every single >>call to every single function in the libxo library. > >sbuf looks like a simple case, returning either ENOMEM or the >error code from the flush function. libxo can keep a "there's >been an error" flag that the user can retrieve, but all the >details of what's gone wrong would be lost. Or it can buffer >the contents of warning messages and deliver it to the caller. We can afford to dedicate a buffer of a reasonable size for that purpose if we need to. The point here is one of API design, and experience has shown that either error-handling is convenient or it doesn't happen. I don't see the libxo case being any different from sbuf in this respect, in fact I see it being almost even more important because the readers are non-humans. libxo should latch on error like libsbuf, and valid output should only be emitted if no errors were encountered during production. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?92A1A2E4-6154-460F-8682-A39F0EB6198C>