On Thu, Mar 28, 2019 at 11:45:06AM -0500, Eric Blake wrote:
On 3/26/19 11:13 AM, Richard W.M. Jones wrote:
I think our options are:
* One-time hack in the rate filter.
* One-time hack in the rate filter, but make it compatible with a possible future revision of parameter handling. eg: If we decided that "rate:file" would in future mean "read ‘rate’ parameter from a file" then we could add this as a simple parameter now but systematize it in future.
So if I understand the proposal, we'd use "name:type" (where :type is optional and defaults to :string), so that in the future we can define other valid types (:file meaning to read from a file, and pay attention to whether that file changes at runtime). It would also mean we could add types such as :int or :size to get nbdkit to do sanity checking that a string is indeed parseable as a particular type of integer, or :bool to automatically use nbdkit_parse_bool, rather than having to open-code those checks in each plugin/filter using a parameter with those types.
I didn't necessarily mean it would have to be that exact scheme, I meant any scheme as long as it could plausibly be implemented properly in future while preserving back-compat. If you can think of something better ...
* Systematize parameters. This would require a great deal of work and likely another version of the API. (I pushed a note into the TODO file for this.)
Have we documented any restrictions on what forms a valid parameter name? If we don't allow ':' in current parameter names, that's nicer (because we can add the extension of 'name:type') than if our new interpretation of ':' could interfere with existing plugin's parameter names. Then again, abusing 'name:type' instead of having an actual struct may be a reason why a v3 protocol that uses an actual struct could be easier to work with.
The code only allows [-A-Za-z0-9._]+ (server/main.c:is_config_key) and this is also documented in the manual. So ':' is currently not permitted in keys. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v