From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NCYck-0007KX-BB
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:06:34 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NCYcf-0007JY-O6
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:06:34 -0500
Received: from [199.232.76.173] (port=39919 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NCYcf-0007JV-Kg
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:06:29 -0500
Received: from mx1.redhat.com ([209.132.183.28]:39561)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <lcapitulino@redhat.com>) id 1NCYcf-0004cX-17
	for qemu-devel@nongnu.org; Mon, 23 Nov 2009 08:06:29 -0500
Date: Mon, 23 Nov 2009 11:06:19 -0200
From: Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 00/10]: QError v4
Message-ID: <20091123110619.4522c7cc@doriath>
In-Reply-To: <4B0961F0.3070004@codemonkey.ws>
References: <1258487037-24950-1-git-send-email-lcapitulino@redhat.com>
	<m33a4bes1c.fsf@crossbow.pond.sub.org>
	<4B04383A.9050101@linux.vnet.ibm.com>
	<m38we27rju.fsf@crossbow.pond.sub.org>
	<4B06C00F.3020107@codemonkey.ws>
	<m3zl6hc9ts.fsf@crossbow.pond.sub.org>
	<4B06E854.7080101@codemonkey.ws>
	<m3iqd48abi.fsf@crossbow.pond.sub.org>
	<4B0961F0.3070004@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: kraxel@redhat.com, Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org

On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> I'm certainly willing to consider alternative ways to do qmp_error() but 
> taking a free form string is not an option in my mind. It goes against 
> the fundamentals of what we're trying to build with QMP.

 Agreed.

> So if you're opposed to structured error data, just having 
> qmp_error(error_code) is a reasonable alternative. I don't think it's 
> the right thing to do, but I think it's still within the spirit of the 
> goals of QMP.

 You mean, we would have calls like:

qemu_error_new(error_code, 'device '%s' not found', name);

 and on the wire:

{ "error": 1234 }

 Did I get it right?

 If so, I can see some problems with it:

1. It's impossible to know what 1234 means by watching the
   protocol on the wire. Although this is a machine protocol,
   this is a good feature

2. We may have errors where having the error data is needed,
   and iirc someone gave an example of this some hundreds
   of emails ago

3. A new error will require a new code. Classes have the
   advantage of becoming stable over time and we'll end up
   just automatically reusing existing ones

 Note that (3) can make class-based error _easier_ to use
as there won't be the need to create new classes over time.

 This is not true for code-based errors. To guarantee there
are no duplicates, we'll have to centralize them in qerror.h,
this means that an enum will have to be updated for *each*
created error.

 I should also say that we're reaching the point where seeing
the current proposal work in practice would be more productive
then discussing it in theory.