From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MyZ4A-000131-4d for qemu-devel@nongnu.org; Thu, 15 Oct 2009 18:45:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MyZ45-00012F-Iv for qemu-devel@nongnu.org; Thu, 15 Oct 2009 18:45:01 -0400 Received: from [199.232.76.173] (port=33360 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MyZ45-00012C-GB for qemu-devel@nongnu.org; Thu, 15 Oct 2009 18:44:57 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:56881) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MyZ45-0001Om-3J for qemu-devel@nongnu.org; Thu, 15 Oct 2009 18:44:57 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e38.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id n9FMeab4017449 for ; Thu, 15 Oct 2009 16:40:36 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9FMinXq168378 for ; Thu, 15 Oct 2009 16:44:50 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9FMinld010213 for ; Thu, 15 Oct 2009 16:44:49 -0600 Subject: Re: [Qemu-devel] [PATCH 6/9] QError: Add qdev not found error From: Hollis Blanchard In-Reply-To: <4AD793C6.9060508@us.ibm.com> References: <1255453026-18637-1-git-send-email-lcapitulino@redhat.com> <1255453026-18637-7-git-send-email-lcapitulino@redhat.com> <1255561330.29192.2.camel@slab.beaverton.ibm.com> <20091015103405.591e2f3b@doriath> <1255626960.29192.7.camel@slab.beaverton.ibm.com> <20091015145208.1d871f09@doriath> <1255630433.29192.16.camel@slab.beaverton.ibm.com> <20091015160839.7dbef5bf@doriath> <1255637617.29192.59.camel@slab.beaverton.ibm.com> <4AD78CCD.6030006@us.ibm.com> <1255641511.29192.68.camel@slab.beaverton.ibm.com> <4AD793C6.9060508@us.ibm.com> Content-Type: text/plain Date: Thu, 15 Oct 2009 15:44:47 -0700 Message-Id: <1255646688.3954.45.camel@slab.beaverton.ibm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kraxel@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On Thu, 2009-10-15 at 16:27 -0500, Anthony Liguori wrote: > hollisb@linux.vnet.ibm.com wrote: > > It's hard enough to keep localized strings updated for every release > > within a single code tree. Beyond that, you expect that every *client* > > will update its localized strings for every *server* release? > > What I meant by highly structured is that you wouldn't pass a string at > all. There would just be an error code and whatever information went > along with that error code. It would be up to the client to decide how > to present a message to the user. > > From a usability perspective, this is better both for localization but > also to ensure a consistent user experience with respect to how errors > are described to a user. > > Basically, I think the conventional wisdom in UI design is that you > never want to pass error messages from a server directly to a user. I think it's also conventional wisdom not to show the user vague "some error occurred" messages. :) How about this (basically what Paolo suggested): { "error": { "code": 12, "desc": "device %{bus}:%{address} already open", "data": { "bus": 0, "address": 12 } } } 'desc' *may* be used by the client, or may be replaced with a localized version. This ensures that users need never be confronted with an "Error: 12" dialog box; a client can at least display some (English) information for unknown errors. I am now seeing how Luiz got to where he did with the original patch: once you have unique error codes, why embed the format string at the call site? (I think this would have been a better patch description in the first place, rather than unspecified "compatibility".) However, I think the part that's still bothering me is the user_print function pointer. It seems to me that there should be no difference between the text sent to a remote client and the text displayed to a local user, and if that were true it would remove some ugliness. -- Hollis Blanchard IBM Linux Technology Center