From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NI1RH-00080A-AQ for qemu-devel@nongnu.org; Tue, 08 Dec 2009 09:53:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NI1RB-0007xG-H3 for qemu-devel@nongnu.org; Tue, 08 Dec 2009 09:53:18 -0500 Received: from [199.232.76.173] (port=34750 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NI1R9-0007wo-FR for qemu-devel@nongnu.org; Tue, 08 Dec 2009 09:53:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58246) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NI0mj-0003RB-IW for qemu-devel@nongnu.org; Tue, 08 Dec 2009 09:11:28 -0500 Date: Tue, 8 Dec 2009 12:11:08 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [FOR 0.12 PATCH 18/18] QMP: add human-readable description to error response Message-ID: <20091208121108.1c4d55a3@doriath> In-Reply-To: <20091208122513.GC16596@redhat.com> References: <1260218236-22143-1-git-send-email-armbru@redhat.com> <1260218236-22143-19-git-send-email-armbru@redhat.com> <20091208101148.119bed20@doriath> <20091208122513.GC16596@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: aliguori@us.ibm.com, Markus Armbruster , qemu-devel@nongnu.org On Tue, 8 Dec 2009 12:25:13 +0000 "Daniel P. Berrange" wrote: > On Tue, Dec 08, 2009 at 10:11:48AM -0200, Luiz Capitulino wrote: > > On Mon, 7 Dec 2009 21:37:16 +0100 > > Markus Armbruster wrote: > > > > > -{ "error": { "class": json-string, "data": json-value }, "id": json-value } > > > +{ "error": { "class": json-string, "data": json-value, "desc": json-string }, > > > + "id": json-value } > > > > > > Where, > > > > > > - The "class" member contains the error class name (eg. "ServiceUnavailable") > > > - The "data" member contains specific error data and is defined in a > > > per-command basis, it will be an empty json-object if the error has no data > > > +- The "desc" member is a human-readable error message. Clients should > > > + not attempt to parse this message. > > > - The "id" member contains the transaction identification associated with > > > the command execution (if issued by the Client) > > > > As we've talked on irc, I don't agree with this change. > > > > Basically, adding 'desc' to the standard error message introduces all > > the problems we've discussed about free-form English strings. > > > > I feel that QError is becoming the worst of all proposals. > > > > I agree with you that it's not as easy as it should be to report errors, > > but as we're targeting on Clients I was convinced that we could not have the > > best API internally but offer a good interface for Clients. > > > > Now, having 'desc' as part of the standard protocol is like not having > > the best API internally and offering a bad interface for Clients. > > > > Not to mention that those strings can't be modified when the protocol > > becomes stable and we're probably talking about dozens if not a hundred > > of strings. Ok, there isn't a reason to change them often, but it's > > still one more thing to maintain. > > I think it is fine to declare that 'desc' strings are subject to > arbitrary change. Even if QEMU includes this 'desc' I think in libvirt > will end up doing its own error code -> human string conversion, > simply because we need to translate the strings. So we'd only use > 'desc' in any logging calls if it were present. That's what we would expect from clients, but I'm not convinced that they'll took the easy way and start using it the way they shouldn't.