Re: [Libguestfs] nbdkit design: varying the rate limit parameter

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.

> * 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.