On Fri, Feb 24, 2017 at 05:04:34PM +0100, Markus Armbruster wrote: > Markus Armbruster <arm...@redhat.com> 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. QAPI outlaws '.' already, > > *Except* in __RFQDN_ prefixes. > > Say example.com needs to add a downstream extension to block driver > "raw". Following QAPI rules, they add to to struct BlockdevOptionsRaw a > new optional member: > > '*__com.example_medium-rare': 'bool' > > On the command line, this looks like > > -blockdev > node-name=foo,driver=raw,__com.example_medium-rare=on,file.driver=file,file.filename=foo.img > > Dotted keys parse this as a reference to member __com's member > example_medium-rare. > > Possible solutions: > > (a) Outlaw domain names with '_'. If KEY starts with "__", everything > up to the third '_' is an __RFQDN_ prefix. > > (b) Outlaw '_' in the name part that follows __RFQDN_. If KEY starts > with "__", everything up to the last '_' is an __RFQDN_ prefix. > > (c) Your bright idea.
Define a new downstream vendor naming convention. IMHO it is reasonable to argue that the downstream vendor extensions are outside the scope of backwards compatibility guarantees we normally apply for our CLI args. Thus, simply say that vendors must replace all '.' with _ in their namespace prefix. eg They should use '__com_example_medium.rare=on' which would mean a property '__com_example_medium' which is a struct containing a property rare with value on Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
