On Mon, 23 Nov 2009 14:50:05 +0100
Alexander Graf ag...@suse.de wrote:
Am 23.11.2009 um 14:34 schrieb Luiz Capitulino lcapitul...@redhat.com:
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Luiz Capitulino wrote:
On Sun, 22 Nov 2009 10:08:16 -0600
On 24.11.2009, at 12:55, Luiz Capitulino wrote:
On Mon, 23 Nov 2009 14:50:05 +0100
Alexander Graf ag...@suse.de wrote:
Am 23.11.2009 um 14:34 schrieb Luiz Capitulino lcapitul...@redhat.com:
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Luiz
On Sat, 21 Nov 2009 11:02:41 +0100
Markus Armbruster arm...@redhat.com wrote:
Now, what should a client do when it discovers the monitor command it
needs to use has grown a new error? Refuse to use the command for fear
of having to present a sub-par error message to the user in case it
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori anth...@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.
Luiz Capitulino wrote:
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori anth...@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
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Luiz Capitulino wrote:
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
I'm certainly willing to consider alternative ways to do qmp_error() but
taking a free form
Am 23.11.2009 um 14:34 schrieb Luiz Capitulino lcapitul...@redhat.com:
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Luiz Capitulino wrote:
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
I'm certainly willing to consider
Anthony Liguori anth...@codemonkey.ws writes:
Markus Armbruster wrote:
I'm thinking and talking primarily about the protocol, and that probably
makes me too terse on implementation.
I didn't mean to suggest that for adding the data part we should add new
arguments providing the data. That
Luiz Capitulino lcapitul...@redhat.com writes:
On Sat, 21 Nov 2009 11:02:41 +0100
Markus Armbruster arm...@redhat.com wrote:
Now, what should a client do when it discovers the monitor command it
needs to use has grown a new error? Refuse to use the command for fear
of having to present a
Markus Armbruster wrote:
I'm thinking and talking primarily about the protocol, and that probably
makes me too terse on implementation.
I didn't mean to suggest that for adding the data part we should add new
arguments providing the data. That would be dumb indeed.
Instead, I'd like to start
Anthony Liguori anth...@codemonkey.ws writes:
Markus Armbruster wrote:
We have:
(1) machine-readable error code
(2) human-readable error message
(3) machine-readable additional error data
The old monitor prints just (3).
s:(3):(2):
D'oh!
You propose to have QMP send (1) and
Jamie Lokier wrote:
Anthony Liguori wrote:
Markus Armbruster wrote:
3. It falls short of the requirement that clients can easily present a
human-readable error description to their human users, regardless of
whether they know the error or not.
That's just incorrect. We
Markus Armbruster wrote:
It's highly likely that for this last case, you'd want generic code to
generate this error. Further more, in order to generate the error
message for a user, you need to know what device does not have a
functioning driver. You may say it's obvious for something like
On Fri, 20 Nov 2009 09:56:46 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Jamie Lokier wrote:
Anthony Liguori wrote:
Markus Armbruster wrote:
3. It falls short of the requirement that clients can easily present a
human-readable error description to their human users,
Luiz Capitulino wrote:
On Fri, 20 Nov 2009 09:56:46 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Jamie Lokier wrote:
Anthony Liguori wrote:
Markus Armbruster wrote:
3. It falls short of the requirement that clients can easily present a
human-readable
Anthony Liguori anth...@codemonkey.ws writes:
Jamie Lokier wrote:
Anthony Liguori wrote:
Markus Armbruster wrote:
3. It falls short of the requirement that clients can easily present a
human-readable error description to their human users, regardless of
whether they know the
Markus Armbruster wrote:
Any particular reason not put it into the error object and be done with
it?
As long as it's generated and not supplied by the caller of
qemu_error_new, I really don't mind.
Regards,
Anthony Liguori
Anthony Liguori anth...@codemonkey.ws writes:
Luiz Capitulino wrote:
On Fri, 20 Nov 2009 09:56:46 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Jamie Lokier wrote:
Anthony Liguori wrote:
Markus Armbruster wrote:
3. It falls short of the requirement
Anthony Liguori anth...@codemonkey.ws writes:
Markus Armbruster wrote:
It's highly likely that for this last case, you'd want generic code to
generate this error. Further more, in order to generate the error
message for a user, you need to know what device does not have a
functioning
Markus Armbruster wrote:
We have:
(1) machine-readable error code
(2) human-readable error message
(3) machine-readable additional error data
The old monitor prints just (3).
s:(3):(2):
You propose to have QMP send (1) and (3). This forces all clients to
come up with (2) themselves.
Anthony Liguori aligu...@linux.vnet.ibm.com writes:
Markus Armbruster wrote:
1. QError feels overengineered, particularly for a first iteration of a
protocol.
We go to great lengths to build highly structured error objects.
There is only one sane reason for doing that: a
I'm sorry, but I'm still quite unhappy with the error reporting part of
QMP.
In short:
1. QError feels overengineered, particularly for a first iteration of a
protocol.
We go to great lengths to build highly structured error objects.
There is only one sane reason for doing that: a
Markus Armbruster wrote:
1. QError feels overengineered, particularly for a first iteration of a
protocol.
We go to great lengths to build highly structured error objects.
There is only one sane reason for doing that: a demonstrated client
need. I can't see that need.
A GUI
Anthony Liguori wrote:
Markus Armbruster wrote:
3. It falls short of the requirement that clients can easily present a
human-readable error description to their human users, regardless of
whether they know the error or not.
That's just incorrect. We provide an example conversion
Hi,
This new QError version has some small improvements and is a candidate
for merging, as qjson is already on master.
Just to remind you that it implements what was suggested by Anthony
in this email:
http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg00601.html
Basically, the error
25 matches
Mail list logo
