On Mon, Oct 05, 2015 at 15:20:58 +0200, Kevin Wolf wrote:
Am 05.10.2015 um 15:01 hat Peter Krempa geschrieben:
> On Mon, Oct 05, 2015 at 14:51:00 +0200, Kevin Wolf wrote:
> > Am 05.10.2015 um 13:01 hat Peter Krempa geschrieben:
> > > On Mon, Oct 05, 2015 at 15:30:42 +0530, Prasanna Kumar Kalever wrote:
...
> > -drive file.driver=gluster,
> > file.volname=testvol,
> > file.image-path=/a.qcow2,
> > file.volfile-servers.0.server=1.2.3.4,
> > file.volfile-servers.0.port=24009,
>
> It looks like that the syntax above can be very well generated from the
> same data structures we use to generate the JSON code. That was also my
> original thought how I'd approach this. On the commandline I'd use the
> syntax above via a separate generator and on monitor we can go with
> json. This will allow us to avoid the uglyness of json on the commannd
> line and the output might perhaps be even shorter.
No, most certainly it won't be shorter.
The biggest drawback of the dot syntax is that it repeats long prefixes
all the time, so contrary to what you might intuitively think, for
humans reading a command line might actually become harder (especially
if options aren't ordered) than with JSON syntax, which at least keeps
all fields of a single object in the same place.
I got carried away by the pretty-formatted json output. You are right,
the output will certainly be longer.
As far as qemu is concerned, you're free to choose whatever you prefer,
though. The first thing that is done with json: filenames is that they
are extracted as if they were separatly specified options, so there's
no semantic difference.
Okay, I'll probably decide arbitrarily by looking at the resulting
strings later, this certainly isn't a pressing issue in this series.
> At any rate we definitely need a parser and a formatter for the json
> options.
You do. :-)
This one is.
Peter