* Markus Armbruster (arm...@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
>
> > * Markus Armbruster (arm...@redhat.com) wrote:
> >> "Dr. David Alan Gilbert" <dgilb...@redhat.com> writes:
> >>
> >> > * Markus Armbruster (arm...@redhat.com) 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 use { KEY=VALUE, ...} for objects, and [ VALUE,
> >> >> ... ] for arrays. Looks like this:
> >> >>
> >> >> -drive 'driver=quorum,
> >> >> child=[{ driver=file, filename=disk1.img },
> >> >> { driver=host_device, filename=/dev/sdb },
> >> >> { driver=nbd, host=localhost } ]'
> >> >>
> >> >> Again, lines broken and indented for legibility; you need to join them
> >> >> for actual use.
> >> >>
> >> >> There's a syntactic catch, though: a value of the form [ ... ] can
> >> >> either be an array or a string. Which one it is depends on the type of
> >> >> the key. To parse this syntax, you need to know the types, unlike JSON
> >> >> or traditional QemuOpts. Unless we outlaw strings starting with '{' or
> >> >> '[', which feels impractical.
> >> >
> >> > I don't understand why [ could imply a string.
> >>
> >> Consider
> >>
> >> -drive 'driver=quorum,
> >> child=[{ driver=file, filename={"foolish":"name"} },
> >> { driver=host_device, filename=/dev/sdb },
> >> { driver=nbd, host=[::1] } ]'
> >>
> >> Three KEY=VALUE have their VALUE start with '[' or '{':
> >>
> >> * child=[{ driver=file, ...
> >>
> >> This is an array, not a string, because child is an array.
> >>
> >> * host=[::1]
> >>
> >> This is a string, not an array containing the string "::1", because
> >> host is a string.
> >
> > Why is that accepted as valid input? Can't that just spit a
> > 'I wanted a string not an array' ?
>
> Because "[::1]" is a perfectly valid string.
>
> It's also a valid array. Unless the parser knows what type to expect
> here, it cannot decide how to parse it. That's why I wrote "to parse
> this syntax, you need to know the types".
I think that's fine; the parser would just parse something starting with
a [ as an array, always. You just define that and then everyone knows
that you'd better " it if you've got a [ in your string.
Dave
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
