Eric Blake <ebl...@redhat.com> writes:
> On 05/05/2014 05:06 AM, Markus Armbruster wrote:
>
>>>
>>> { 'command': 'block-commit',
>>> 'data': { 'device': 'str', '*base': 'str', 'top': 'str',
>>> '*speed': 'int' },
>>> 'defaults': {'base': 'earthquake', 'speed': 100 } }
>>>
>
>>
>> Can we keep a parameter's properties together? Perhaps like this:
>>
>> NAME: { 'type': TYPE, 'default': DEFAULT }
>>
>> where
>>
>> NAME: { 'type': TYPE }
>>
>> can be abbreviated to
>>
>> NAME: TYPE
>
> I like it. It also means:
>
> data: { '*foo': { 'type': 'str', 'default': 'hello' } }
>
> is invalid - a defaulted argument is NOT spelled '*foo' but merely 'foo'.
>
>>
>> and
>>
>> NAME: { 'type': TYPE, 'default': null }
>> to
>>
>> NAME-PREFIXED-BY_ASKTERISK: TYPE
>>
>> if we think these abbreviations enhance schema readability enough to be
>> worthwhile. The first one does, in my opinion. but I'm not so sure
>> about the second one.
>
> Or, putting the question in reverse, you are asking if:
>
> data: { '*foo': 'str' }
>
> can blindly be rewritten into:
>
> data: { 'foo': { 'type': 'str', 'default': null } }
>
> and the rest of the introspection use the fact that 'default':null
> implies that the argument is optional but has no specified default, and
> therefore still needs the has_foo magic.
>
> As you say, it's a bit more of a stretch, but does make introspection
> nice (introspection already has to deal with leading '*' to turn it into
> something nicer to pass over the wire - if we ever get introspection
> working). I'd have to see it actually coded up to decide for sure if it
> turned out to be a net win.
Glad you mention introspection; I didn't think of it.
The "an asterisk at the beginning of a name is not part of the name, but
means the parameter is optional" thing is a deviation from our usual
design rule against parsing strings in addition to JSON. My proposal to
make the "is optional" property an ordinary JSON member straightens this
out.
The bit I'm not sure about is whether we want to keep the
NAME-PREFIXED-BY-ASKTERISK: TYPE form as syntactic sugar.
Keeping the TYPE: NAME form as sugar makes sense to me, because it cuts
noise in the schema while adding no syntax beyond JSON.
The schema parser desugars its input. Sugaring schema introspection
output makes no sense to me, because all that accomplishes is
introspection users have to duplicate the schema parser's desugaring.
