From owner-freebsd-arch@FreeBSD.ORG Thu Aug 14 05:26:59 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 4E90E7CB; Thu, 14 Aug 2014 05:26:59 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E22E72237; Thu, 14 Aug 2014 05:26:58 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s7E5QmCG052829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Aug 2014 08:26:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s7E5QmCG052829 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s7E5QmM4052828; Thu, 14 Aug 2014 08:26:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Aug 2014 08:26:48 +0300 From: Konstantin Belousov To: Phil Shafer Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <20140814052648.GM2737@kib.kiev.ua> References: <201408131936.s7DJaA1r089174@idle.juniper.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iUV/lbBrmPtUT9dM" Content-Disposition: inline In-Reply-To: <201408131936.s7DJaA1r089174@idle.juniper.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: arch@freebsd.org, Poul-Henning Kamp , marcel@freebsd.org, John-Mark Gurney , "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 05:26:59 -0000 --iUV/lbBrmPtUT9dM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 13, 2014 at 03:36:10PM -0400, Phil Shafer wrote: > Phil Shafer writes: > >FWIW, the UTF-8 strategy for libox is this: > >- all format strings are UTF-8 > >- argument strings (%s) are UTF-8 > >- "%ls" handles wide characters > >- "%hs" will handle locale-based strings > >- XML, JSON, and HTML will be UTF-8 output > >- text will be locale-based >=20 > Sorry for the delay, but this code is now done. Formatting widths > are done using wcwidth() so things like "%15.15s" work correctly > regardless of locale settings. As a background task, I'm converting > some basic commands to use libxo. It's slow work, but needs done.... >=20 > I've a related topic: when an app goes to run a child command, how > can it determine whether that binary supports libxo-based encoding > requests? This should be known before the binary is run, since > there's no means of auto-detecting the supported output after the > fact. >=20 > For example, say I want to make a JSON-based API for my server. I > can setenv("LIBXO_OPTIONS", "json") to get JSON output, but I won't > know if the binary supports this or if the output needs to be wrapped > and escaped. >=20 > I know ELF "Note" elements can be used to carry vendor-specific > data, but have no experience with them. Would it be reasonable to > use them as a means of communicating this information to other bits > of software? No. > Is FreeBSD using Notes for other information currently? Yes, the notes are used to communicate the information required by the dynamic linker to correctly activate the image. The mechanism has nothing to do with application-specific features, and overloading it for that purpose is severe and pointless layering violation. Things should not be done just because they could be done. Using the static tagging for the dynamic application properties is wrong anyway. E.g., would you consider the mere fact that the binary is linked against your library, as the indication that your feature is supported ? If not, how does it differ from the presence of some additional note ? --iUV/lbBrmPtUT9dM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT7EiXAAoJEJDCuSvBvK1BOKoP/1zGvwB4g3dkL+/oLInckVPD NEeNWyXgExYOCMkA9yNMhqagxT7t42VbvyacElOQb/kGdZImbKsxuqbdr+pWEOng nYb4EGG+ORS/21jkcEE84WwQrZzwNsnavr2NUJPQd4NML19Y+zKGwIpLK+oguYKM sILBXLxVmmI2Z/ef8O7J8l69MsaP+llPo5lOgcFE6D/DsAjSNQyRSFAMDODB3V7+ na1rGqNSvQNfNR5w3YQUYtSo/htDKy4hkZphayQTP68EFE8gM5lv7pqIV3GABvq1 dIjDDhzTAtlsi2U5Z4cL/RV+bWHYwKYatHAgJKFiuMx+MkOw/GLXOTVO0kZcQyV4 OGVVEZ+xURnKNaHYaozy520EoYlCz4rkOGvP8O9yiB0qdhjXDF1RJptlGByx30K0 4fRA7vKG61Aks92XR+jezhu0AcLXcKnighgi46L+/HfEYM63Tqoyvm6MkE1JVMb4 idkKxO4dH/91CXv/CeNYpSeZLtfXtaT6Y2oknlh5+uJlVOYS2Dg/ambwcyDqowjb qGHGy6PQz9kdEAbTj16LYTWpPNlpNXHy7r6n7P4ufIB0lsnVFw6mrJ5XGmzoRe3D SmxSS0eg4oMsOargh/W5DxkyRg5Wk3cCFZU8j4g7kpvmN6sIqShP8Gcp6/qqUKEd lXhD6rit2OI265CDBbGY =2x00 -----END PGP SIGNATURE----- --iUV/lbBrmPtUT9dM--