glossary: Make objects explicitly unordered and forbid duplicate names #584
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Pin down our JSON definition to a particular RFC (which we can explicitly bump if neccessary), instead of referencing the floating JSON homepage. Explicitly make objects unordered and forbid duplicate names to avoid relying on unportable behavior. RFC 7159 is a bit more relaxed [1]: The names within an object SHOULD be unique. but warns [1]: An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates. The RFC also warns about order portability [1]: JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences. And has some (informative?) language about entries being unordered [2]: An object is an unordered collection of zero or more name/value pairs... [1]: https://tools.ietf.org/html/rfc7159#section-4 [2]: https://tools.ietf.org/html/rfc7159#section-1 Signed-off-by: W. Trevor King <wking@tremily.us>
|
LGTM |
1 similar comment
|
LGTM |
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 27, 2016
Namespaces do not need repeated entries and the ordering is handled by the runtime regardless of the spec ordering (e.g. in runC [1]). Using an object leans on the new wording from eeaccfa (glossary: Make objects explicitly unordered and forbid duplicate names, 2016-09-27, opencontainers#584) to make both of those points explicit. [1]: opencontainers/runc#977 Subject: nsenter: guarantee correct user namespace ordering Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 27, 2016
Rlimits do not need either ordering or repeat entries for a single type. Using an object leans on the new wording from eeaccfa (glossary: Make objects explicitly unordered and forbid duplicate names, 2016-09-27, opencontainers#584) to make both of those points explicit. Also add Solaris support. I'm not entirely clear on this, because while Solaris is POSIX-certified system and there is a Solaris man page for setrlimit, Abhijeeth claims no Solaris support for rlimits [1]. The additionalProperties object bit comes from [2,3], although it is not documented in draft 4 of the JSON Schema RFC [4]. [1]: opencontainers#564 (comment) [2]: https://spacetelescope.github.io/understanding-json-schema/reference/object.html#properties [3]: https://tools.ietf.org/html/draft-wright-json-schema-validation-00#section-5.18 [4]: https://tools.ietf.org/html/draft-zyp-json-schema-04 Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 27, 2016
Namespaces do not need repeated entries and the ordering is handled by the runtime regardless of the spec ordering (e.g. in runC [1]). Using an object leans on the new wording from eeaccfa (glossary: Make objects explicitly unordered and forbid duplicate names, 2016-09-27, opencontainers#584) to make both of those points explicit. [1]: opencontainers/runc#977 Subject: nsenter: guarantee correct user namespace ordering Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 27, 2016
Namespaces do not need repeated entries and the ordering is handled by the runtime regardless of the spec ordering (e.g. in runC [1]). Using an object leans on the new wording from eeaccfa (glossary: Make objects explicitly unordered and forbid duplicate names, 2016-09-27, opencontainers#584) to make both of those points explicit. [1]: opencontainers/runc#977 Subject: nsenter: guarantee correct user namespace ordering Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Nov 3, 2016
Rlimits do not need either ordering or repeat entries for a single type. Using an object leans on the new wording from eeaccfa (glossary: Make objects explicitly unordered and forbid duplicate names, 2016-09-27, opencontainers#584) to make both of those points explicit. Also add Solaris support. I'm not entirely clear on this, because while Solaris is POSIX-certified system and there is a Solaris man page for setrlimit, Abhijeeth claims no Solaris support for rlimits [1]. The additionalProperties object bit comes from [2,3], although it is not documented in draft 4 of the JSON Schema RFC [4]. [1]: opencontainers#564 (comment) [2]: https://spacetelescope.github.io/understanding-json-schema/reference/object.html#properties [3]: https://tools.ietf.org/html/draft-wright-json-schema-validation-00#section-5.18 [4]: https://tools.ietf.org/html/draft-zyp-json-schema-04 Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
May 26, 2017
This condition landed in 27a05de (Add text about extensions, 2016-06-26, opencontainers#510) with subsequent wording tweaks in 3f0440b (config.md: add empty limit for key of annotations, Dec 28 10:35:19 2016, opencontainers#645) and 2c8feeb (config: Bring "unique... within this map" back together, 2017-01-12, opencontainers#654). However, since eeaccfa (glossary: Make objects explicitly unordered and forbid duplicate names, 2016-09-27, opencontainers#584) we forbid duplicate keys on *all* objects (not just annotations), so this PR removes the redundant annotation-specific condition. Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Jun 1, 2017
This condition landed in 27a05de (Add text about extensions, 2016-06-26, opencontainers#510) with subsequent wording tweaks in 3f0440b (config.md: add empty limit for key of annotations, Dec 28 10:35:19 2016, opencontainers#645) and 2c8feeb (config: Bring "unique... within this map" back together, 2017-01-12, opencontainers#654). However, since eeaccfa (glossary: Make objects explicitly unordered and forbid duplicate names, 2016-09-27, opencontainers#584) we forbid duplicate keys on *all* objects (not just annotations), so this PR removes the redundant annotation-specific condition. Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pin down our JSON definition to a particular RFC (which we can explicitly bump if neccessary), instead of referencing the floating JSON homepage.
Explicitly make objects unordered and forbid duplicate names to avoid relying on unportable behavior. RFC 7159 is a bit more relaxed:
but warns:
The RFC also warns about order portability:
And has some (informative?) language about entries being unordered: