You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 14, 2020. It is now read-only.
Is there any particular reason why the "name" and "value" keys are used for labels, annotations, isolators, eventHandlers and environment variable lists? If those things were objects themselves, instead of lists, the ACI image schema would be much simpler and less verbose.
For instance, if you made the lists into objects for the above mentioned attributes of the image schema, you would go from this (from the examples):
Hmm, this has been discussed before in #58, #62, #64, and #84 and we landed on the more verbose format. To reiterate here:
It maintains that field names on the left are schema, values on the right are user values. Behavior during duplicate JSON object field names are not part of the JSON spec and may be handled differently based on the library being used...but generally an ill-formed manifest will have duplicate errors swallowed during JSON parsing. Some label names are not valid JSON object member names.
OK, that's good information, thank you. I guess I don't really see why AppC would use JSON as its file format and then allow "label names [to not be] valid JSON object member names." That doesn't make a whole lot of sense to me. Why bother using JSON at all, then, if you're just going to override what JSON means with the parser.go implementation? Or, put another way, what does not conforming to the JSON spec give AppC?
I guess I don't really see why AppC would use JSON as its file format and then allow "label names [to not be] valid JSON object member names." That doesn't make a whole lot of sense to me. Why bother using JSON at all, then, if you're just going to override what JSON means with the parser.go implementation? Or, put another way, what does not conforming to the JSON spec give AppC?
I'm a bit confused by @cdaylward's point here, as I don't know of cases where label names are invalid member names.
As justification for this schema I would lean more on his other points with respect to the field name/user value split.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi again!
Is there any particular reason why the "name" and "value" keys are used for labels, annotations, isolators, eventHandlers and environment variable lists? If those things were objects themselves, instead of lists, the ACI image schema would be much simpler and less verbose.
For instance, if you made the lists into objects for the above mentioned attributes of the image schema, you would go from this (from the examples):
to this:
The latter doesn't lose any information, and is significantly less verbose (and IMHO easier to read).
Thoughts?
Best,
-jay
The text was updated successfully, but these errors were encountered: