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 > >>> 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. > >>> > >>> > >>>> 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); > >>> > >> > >> Except drop the 'device %s not found' bit. > > > > We would need a table to have the strings for the user protocol > > then. Not having the table is a key point in Markus's argument, > > I guess. > > We would need that for internationalization anyways, right? > > Though I don't dislike the idea of passing a plain default syntax over > the wire as a bonus / fallback. Especially for cases where the ui is > older than qemu. > > So why not have the table inside qemu do a lookup and send that as > default format in addition to the error code (that should usually be > used to find out the format)? The current proposal does have a table, the argument against it is that we're making error reporting complex, as developers will have to edit more than one place to report errors.
