For the record, we went with "either dotted keys or JSON" for -blockdev
in 2.9.
Certain uses of QAPI become problematic with dotted keys, because
(1) it's untyped except for inner tree nodes, and therefore can't
express numbers, boolean, null, empty list, empty object, and
(2) The keyval variant
Markus Armbruster writes:
[...]
> == Extensions of the traditional syntax ==
>
> Even if we accept JSON in addition to the traditional KEY=VALUE,...
> syntax, we might want to make the traditional syntax more expressive
> anyway. Do we?
>
> Kevin brought up an argument for yes: without it, going
Eric Blake writes:
> On 02/27/2017 04:27 AM, Markus Armbruster wrote:
>> Design flaw: there is no good way to denote an empty array or object
>> other than the root object.
>>
>> Empty KEY=VALUE,... is valid and results in an empty root object.
>>
>> Presence of a KEY that contains periods resu
Eric Blake writes:
> On 02/27/2017 07:36 AM, Markus Armbruster wrote:
>
>>
>>> Maybe just 'foo.array[]' (without any =) for an empty
>>> array or something like that.
>>
>> Yes, that should do. Likewise foo.object{} for empty object.
>>
>> {} doesn't even need quoting. [] ma
On 02/27/2017 04:27 AM, Markus Armbruster wrote:
> Design flaw: there is no good way to denote an empty array or object
> other than the root object.
>
> Empty KEY=VALUE,... is valid and results in an empty root object.
>
> Presence of a KEY that contains periods results in additional non-root
>
On 02/27/2017 07:36 AM, Markus Armbruster wrote:
>
>> Maybe just 'foo.array[]' (without any =) for an empty
>> array or something like that.
>
> Yes, that should do. Likewise foo.object{} for empty object.
>
> {} doesn't even need quoting. [] may.
[contents] needs quoting, b
Kevin Wolf writes:
> Am 27.02.2017 um 11:27 hat Markus Armbruster geschrieben:
>> Markus Armbruster writes:
>>
>> [...]
>> > === Dotted keys ===
>> >
>> > One sufficiently powerful syntax extension already exists: the dotted
>> > key convention. It's syntactically unambiguous only when none of
Am 27.02.2017 um 11:27 hat Markus Armbruster geschrieben:
> Markus Armbruster writes:
>
> [...]
> > === Dotted keys ===
> >
> > One sufficiently powerful syntax extension already exists: the dotted
> > key convention. It's syntactically unambiguous only when none of the
> > KEYs involved contain
Markus Armbruster writes:
[...]
> === Dotted keys ===
>
> One sufficiently powerful syntax extension already exists: the dotted
> key convention. It's syntactically unambiguous only when none of the
> KEYs involved contains '.' To adopt it across the board, we'd have to
> outlaw '.' in KEYs. Q
Eric Blake writes:
> On 02/24/2017 10:39 AM, Daniel P. Berrange wrote:
>> On Fri, Feb 24, 2017 at 05:04:34PM +0100, Markus Armbruster wrote:
>>> Markus Armbruster writes:
>>>
>>> [...]
=== Dotted keys ===
One sufficiently powerful syntax extension already exists: the dotted
k
On 02/24/2017 10:39 AM, Daniel P. Berrange wrote:
> On Fri, Feb 24, 2017 at 05:04:34PM +0100, Markus Armbruster wrote:
>> Markus Armbruster writes:
>>
>> [...]
>>> === Dotted keys ===
>>>
>>> One sufficiently powerful syntax extension already exists: the dotted
>>> key convention. It's syntactica
On Fri, Feb 24, 2017 at 05:04:34PM +0100, Markus Armbruster wrote:
> Markus Armbruster writes:
>
> [...]
> > === Dotted keys ===
> >
> > One sufficiently powerful syntax extension already exists: the dotted
> > key convention. It's syntactically unambiguous only when none of the
> > KEYs involve
Markus Armbruster writes:
[...]
> === Dotted keys ===
>
> One sufficiently powerful syntax extension already exists: the dotted
> key convention. It's syntactically unambiguous only when none of the
> KEYs involved contains '.' To adopt it across the board, we'd have to
> outlaw '.' in KEYs. Q
Am 06.02.2017 um 16:36 hat Markus Armbruster geschrieben:
> >> === Structured values ===
> >>
> >> The dotted key convention messes with KEY syntax to permit structured
> >> values. Works, but the more conventional way to support structured
> >> values is a syntax for structured values.
> >>
>
Paolo Bonzini writes:
> On 06/02/2017 19:12, Markus Armbruster wrote:
>>> QOM now supports class properties. We can convert the wide majority of
>>> them, including qdev's "static" properties, to class properties.
>>
>> Won't help object-add as long as dynamic properties remain.
>
> Well, only
On 06/02/2017 19:12, Markus Armbruster wrote:
>> QOM now supports class properties. We can convert the wide majority of
>> them, including qdev's "static" properties, to class properties.
>
> Won't help object-add as long as dynamic properties remain.
Well, only as long as dynamic properties r
Note: a bit more context restored.
"Daniel P. Berrange" writes:
> On Mon, Feb 06, 2017 at 06:24:42PM +0100, Markus Armbruster wrote:
>> "Daniel P. Berrange" writes:
>>
>> > On Mon, Feb 06, 2017 at 04:36:50PM +0100, Markus Armbruster wrote:
>> >> Kevin Wolf writes:
>> >>
>> >> > Am 02.02.2017
Paolo Bonzini writes:
> On 06/02/2017 16:36, Markus Armbruster wrote:
>> Example: QOM properties and object-add, qom-set, qom-get
>>
>> QOM properties are created at run-time. They cannot be fixed at
>> compile-time *by design*. I always hated that part of the design, but I
>> was assured we a
On Mon, Feb 06, 2017 at 06:24:42PM +0100, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
> > On Mon, Feb 06, 2017 at 04:36:50PM +0100, Markus Armbruster wrote:
> >> Kevin Wolf writes:
> >> > Want to make use of the shiny new QemuOpts and get things parsed into
> >> > a nested object?
On 06/02/2017 16:36, Markus Armbruster wrote:
> Example: QOM properties and object-add, qom-set, qom-get
>
> QOM properties are created at run-time. They cannot be fixed at
> compile-time *by design*. I always hated that part of the design, but I
> was assured we absolutely need that much rope
"Daniel P. Berrange" writes:
> On Mon, Feb 06, 2017 at 04:36:50PM +0100, Markus Armbruster wrote:
>> Kevin Wolf writes:
>> > Want to make use of the shiny new QemuOpts and get things parsed into
>> > a nested object? Well, provide a real schema instead of "any" then.
>>
>> Sadly, this is somewh
On Mon, Feb 06, 2017 at 04:36:50PM +0100, Markus Armbruster wrote:
> Kevin Wolf writes:
> > Want to make use of the shiny new QemuOpts and get things parsed into
> > a nested object? Well, provide a real schema instead of "any" then.
>
> Sadly, this is somewhere between impractical and impossible
Kevin Wolf writes:
> Am 02.02.2017 um 20:42 hat Markus Armbruster geschrieben:
>> = Brief recap of dotted key convention =
>>
>> We'll discuss use of dotted key convention later, so let me explain it
>> briefly for the readers who don't know it already.
>>
>> The dotted key convention interpret
Am 02.02.2017 um 20:42 hat Markus Armbruster geschrieben:
> = Brief recap of dotted key convention =
>
> We'll discuss use of dotted key convention later, so let me explain it
> briefly for the readers who don't know it already.
>
> The dotted key convention interprets the KEY part as a sequence
On Sat, Feb 04, 2017 at 08:21:50PM +0800, Fam Zheng wrote:
> On Thu, 02/02 20:42, Markus Armbruster wrote:
> > === Comparison ===
> >
> > In my opinion, dotted keys are weird and ugly, but at least they don't
> > add to the quoting mess. Structured values look better, except when
> > they do add
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> "Dr. David Alan Gilbert" writes:
> >>
> >> > * Markus Armbruster (arm...@redhat.com) wrote:
> [...]
> >> >> === Structured values ===
> >> >>
> >> >> The
Markus Armbruster writes:
[...]
> === Structured values ===
>
> The dotted key convention messes with KEY syntax to permit structured
> values. Works, but the more conventional way to support structured
> values is a syntax for structured values.
>
> An obvious one is to use { KEY=VALUE, ...}
Fam Zheng writes:
> On Sat, 02/04 14:35, Markus Armbruster wrote:
>> Fam Zheng writes:
>>
>> > On Thu, 02/02 20:42, Markus Armbruster wrote:
>> >> === Comparison ===
>> >>
>> >> In my opinion, dotted keys are weird and ugly, but at least they don't
>> >> add to the quoting mess. Structured va
On Sat, 02/04 14:35, Markus Armbruster wrote:
> Fam Zheng writes:
>
> > On Thu, 02/02 20:42, Markus Armbruster wrote:
> >> === Comparison ===
> >>
> >> In my opinion, dotted keys are weird and ugly, but at least they don't
> >> add to the quoting mess. Structured values look better, except when
Fam Zheng writes:
> On Thu, 02/02 20:42, Markus Armbruster wrote:
>> === Comparison ===
>>
>> In my opinion, dotted keys are weird and ugly, but at least they don't
>> add to the quoting mess. Structured values look better, except when
>> they do add to the quoting mess.
>>
>> I'm having a har
On Sat, 02/04 04:44, Paolo Bonzini wrote:
>
>
> On 04/02/2017 04:21, Fam Zheng wrote:
> > -json "id=children0,text=[
> > { 'driver': 'null-co://' },
> > { 'driver': 'null-co://' },
>
> You meant ,, at the end of this lines. Which throws a wrench in your
> pro
On 04/02/2017 04:21, Fam Zheng wrote:
> -json "id=children0,text=[
> { 'driver': 'null-co://' },
> { 'driver': 'null-co://' },
You meant ,, at the end of this lines. Which throws a wrench in your
proposal somewhat. :(
Paolo
> { 'driver': 'nu
On 04/02/2017 03:52, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 04/02/2017 01:45, Markus Armbruster wrote:
> -drive driver=qcow2,
> file.driver=gluster,
> .volume=testvol,
> .path=/path/a.qcow2,
>
On Thu, 02/02 20:42, Markus Armbruster wrote:
> === Comparison ===
>
> In my opinion, dotted keys are weird and ugly, but at least they don't
> add to the quoting mess. Structured values look better, except when
> they do add to the quoting mess.
>
> I'm having a hard time deciding which one I l
Paolo Bonzini writes:
> On 04/02/2017 01:45, Markus Armbruster wrote:
-drive driver=qcow2,
file.driver=gluster,
.volume=testvol,
.path=/path/a.qcow2,
.debug=9,
file.server.0.type=tcp,
On 04/02/2017 01:45, Markus Armbruster wrote:
>>> -drive driver=qcow2,
>>> file.driver=gluster,
>>> .volume=testvol,
>>> .path=/path/a.qcow2,
>>> .debug=9,
>>> file.server.0.type=tcp,
>>> .host=1
"Richard W.M. Jones" writes:
> On Thu, Feb 02, 2017 at 08:42:33PM +0100, Markus Armbruster wrote:
>> There's also the -drive file=json:... syntax. It's a bad fit for
>> QemuOpts, because QemuOpts and JSON fight for the comma. I'd show you
>> if I could get it to work.
>
> I think this refers to
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> "Dr. David Alan Gilbert" writes:
>>
>> > * Markus Armbruster (arm...@redhat.com) wrote:
[...]
>> >> === Structured values ===
>> >>
>> >> The dotted key convention messes with KEY syntax to permit structured
>
On Thu, Feb 02, 2017 at 08:42:33PM +0100, Markus Armbruster wrote:
> There's also the -drive file=json:... syntax. It's a bad fit for
> QemuOpts, because QemuOpts and JSON fight for the comma. I'd show you
> if I could get it to work.
I think this refers to the json: syntax for qemu URIs?
Anywa
* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> = Introduction =
> >>
> >
> >
> >
> >> = Structured option argument syntax =
> >>
> >> == JSON ==
> >>
> >> The obvious way to provide the expressiveness
Peter Krempa writes:
> On Thu, Feb 02, 2017 at 20:42:33 +0100, Markus Armbruster wrote:
>
> [...]
>
>> === Comparison ===
>>
>> In my opinion, dotted keys are weird and ugly, but at least they don't
>> add to the quoting mess. Structured values look better, except when
>> they do add to the quo
On Thu, Feb 02, 2017 at 20:42:33 +0100, Markus Armbruster wrote:
[...]
> === Comparison ===
>
> In my opinion, dotted keys are weird and ugly, but at least they don't
> add to the quoting mess. Structured values look better, except when
> they do add to the quoting mess.
From libvirt's point o
"Daniel P. Berrange" writes:
> On Thu, Feb 02, 2017 at 08:42:33PM +0100, Markus Armbruster wrote:
>> === Dotted keys ===
>>
>> One sufficiently powerful syntax extension already exists: the dotted
>> key convention. It's syntactically unambiguous only when none of the
>> KEYs involved contains
On Thu, Feb 02, 2017 at 08:42:33PM +0100, Markus Armbruster wrote:
> === Dotted keys ===
>
> One sufficiently powerful syntax extension already exists: the dotted
> key convention. It's syntactically unambiguous only when none of the
> KEYs involved contains '.' To adopt it across the board, we'
Eric Blake writes:
> On 02/02/2017 01:42 PM, Markus Armbruster wrote:
>
>>
>> === Structured values ===
>>
>> The dotted key convention messes with KEY syntax to permit structured
>> values. Works, but the more conventional way to support structured
>> values is a syntax for structured values.
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>> = Introduction =
>>
>
>
>
>> = Structured option argument syntax =
>>
>> == JSON ==
>>
>> The obvious way to provide the expressiveness of JSON on the command
>> line is JSON. Easy enough[2]. However, besid
* Markus Armbruster (arm...@redhat.com) wrote:
> = Introduction =
>
> = Structured option argument syntax =
>
> == JSON ==
>
> The obvious way to provide the expressiveness of JSON on the command
> line is JSON. Easy enough[2]. However, besides not being compatible,
> it's rather heavy on s
On 02/02/2017 01:42 PM, Markus Armbruster wrote:
>
> === Structured values ===
>
> The dotted key convention messes with KEY syntax to permit structured
> values. Works, but the more conventional way to support structured
> values is a syntax for structured values.
>
> An obvious one is to u
On 02/02/2017 01:42 PM, Markus Armbruster wrote:
quick comment before I reply to the overall message...
> Arbitrary nesting with dotted key convention:
>
> -drive driver=qcow2,file.driver=gluster,
>file.volume=testvol,file.path=/path/a.qcow2,file.debug=9,
>file.serve
= Introduction =
If you're familiar with prior discussion of non-flat arguments for
-object and -blockdev, you can probably skip ahead to "= Structured
option argument syntax =".
Structured option arguments use KEY=VALUE,... syntax. Goes back many
years (at least to commit 7c9d8e0, Nov 2005). S
50 matches
Mail list logo
