On 24.11.2009, at 12:55, Luiz Capitulino wrote:
> On Mon, 23 Nov 2009 14:50:05 +0100
> Alexander Graf wrote:
>
>>
>> Am 23.11.2009 um 14:34 schrieb Luiz Capitulino :
>>
>>> On Mon, 23 Nov 2009 07:11:53 -0600
>>> Anthony Liguori wrote:
>>>
Luiz Capitulino wrote:
> On Sun, 22 Nov 200
On Mon, 23 Nov 2009 14:50:05 +0100
Alexander Graf wrote:
>
> Am 23.11.2009 um 14:34 schrieb Luiz Capitulino :
>
> > On Mon, 23 Nov 2009 07:11:53 -0600
> > Anthony Liguori wrote:
> >
> >> Luiz Capitulino wrote:
> >>> On Sun, 22 Nov 2009 10:08:16 -0600
> >>> Anthony Liguori wrote:
> >>>
> >>>
>
Luiz Capitulino writes:
> On Sat, 21 Nov 2009 11:02:41 +0100
> Markus Armbruster 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 use
Anthony Liguori 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 would be du
Am 23.11.2009 um 14:34 schrieb Luiz Capitulino :
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori wrote:
Luiz Capitulino wrote:
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori wrote:
I'm certainly willing to consider alternative ways to do qmp_error
() but
taking a free form string
On Mon, 23 Nov 2009 07:11:53 -0600
Anthony Liguori wrote:
> Luiz Capitulino wrote:
> > On Sun, 22 Nov 2009 10:08:16 -0600
> > Anthony Liguori 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 min
Luiz Capitulino wrote:
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori 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.
On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori 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 oppo
On Sat, 21 Nov 2009 11:02:41 +0100
Markus Armbruster 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
> fails?
What's you
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 w
Anthony Liguori 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
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 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 driver. You ma
Anthony Liguori writes:
> Luiz Capitulino wrote:
>> On Fri, 20 Nov 2009 09:56:46 -0600
>> Anthony Liguori wrote:
>>
>>
>>> Jamie Lokier wrote:
>>>
Anthony Liguori wrote:
> Markus Armbruster wrote:
>
>> 3. It falls short of the requirement that
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 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
Luiz Capitulino wrote:
On Fri, 20 Nov 2009 09:56:46 -0600
Anthony Liguori 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 t
On Fri, 20 Nov 2009 09:56:46 -0600
Anthony Liguori 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, reg
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 info
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 pro
Anthony Liguori 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 demonstrated client
>>n
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 c
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 wan
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 demon
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 t
25 matches
Mail list logo
