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
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list