On 02/05/2018 14:36, Markus Armbruster wrote: >> The purpose of this command is to tell people/tools what they can pass >> to -device/-object/device_add/object_add, so the real question is >> whether there are cases where it falls short of that purpose. >> >> If not, > > Do we have to be certain? Or would "we don't think so" be enough?
I think it's enough. >> maybe the wording for the .json file could be something like: >> >> Objects can create properties at runtime, for example to describe >> links between different devices and/or objects. These properties >> are not included in the output of this command. > > Not bad. Thanks. :) > In theory, objects can also create properties in response to non-default > configuration, and these would also not be included. Objects could even > create a property with the same name, but different type or description. > Arguably capital-letter Bad Ideas, but nothing prevents such misuse. > > Since I'm in a generous mood, I'd rate the thing at Rusty API level 4 > "Follow common convention and you'll get it right." > > https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html > https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html > > If dynamic properties are really just for internal use I wouldn't say they are for internal use. They are somewhat orthogonal to the _intended_ use case of this command though. Somebody is bound to be annoyed by them anyway, but that's sort of expected with dynamic stuff. > , as you seem to > suggest in Message-ID: > <c1d40d88-1c80-2bbd-c28c-613b7fe8d...@redhat.com>, then we should've had > the common sense to unambiguously separate them from the user-facing > properties. Can we still do that? We do have infrastructure for class properties, we just don't use it much. Paolo
