[Tracker] Platform/Compiler agnostic schema

[vbatts]

like #135 began to fix, this needs to track our movement from golang compiler constrained schema, to something like json-schema.
At that point, we can have the provided *.go (if at all) as a reference for valid structs for the schema.

[wking]

On Wed, Sep 09, 2015 at 10:30:24AM -0700, Vincent Batts wrote:

like #135 began to fix…

How is this related to #135?

… this needs to track our movement from golang compiler constrained
schema, to something like json-schema.

JSON Schema is fine with me (although their docs can be hard to browse
;). Are any other schema languages under consideration? If we're all
on-board with JSON Schema, I'd just start working on it :p. If we
don't think everybody's on board, I'd suggest floating alternatives on
the mailing list, and linking to the list thread from this issue.

[dqminh]

I think a richer schema is definitely beneficial.

Does json schema support things like one field can have different types (like uid/gid can be string on windows iirc ), and oneOf/anyOf relationship for things like Resources/CgroupPaths etc. ?

[wking]

On Wed, Sep 09, 2015 at 11:25:47AM -0700, Daniel, Dao Quang Minh wrote:

Does json schema support things like one field can have different
types (like uid/gid can be string on windows iirc ),

That sounds like oneOf.

… and oneOf/anyOf relationship for things like
Resources/CgroupPaths etc. ?

Yes, see 1.

Maybe the approach should be “start translating the spec to JSON
Schema (or any other proposed schema language), and then compare the
partial translations to see which feels most expressive”?

[vbatts]

@wking it's related to #135 because the schema is presently tied up in source that will compile differently on various platforms. So to have a way, for instance, to validate a linux config, from an OSX host, is not straight forward. This is what we were talking about on the call today.

[wking]

On Wed, Sep 09, 2015 at 07:53:07PM -0700, Vincent Batts wrote:

@wking it's related to #135 because the schema is presently tied up
in source that will compile differently on various platforms…

#135 is a step towards a platform-agnostic Go spec. Is that a valid
end-goal? It may be better than a platform-specific Go spec, but it
seems like dead-end work if this issue gets traction for a non-Go spec
language. On the other hand, if we expect a non-Go spec to take a
while, it may still be useful dead-end work ;).

[vbatts]

This is about not yak shaving, and actually trying to solve the problem
#135 was pursuing.

On Wed, Sep 9, 2015 at 11:21 PM, W. Trevor King notifications@github.com
wrote:

On Wed, Sep 09, 2015 at 07:53:07PM -0700, Vincent Batts wrote:

@wking it's related to #135 because the schema is presently tied up
in source that will compile differently on various platforms…

#135 is a step towards a platform-agnostic Go spec. Is that a valid
end-goal? It may be better than a platform-specific Go spec, but it
seems like dead-end work if this issue gets traction for a non-Go spec
language. On the other hand, if we expect a non-Go spec to take a
while, it may still be useful dead-end work ;).

—
Reply to this email directly or view it on GitHub
#166 (comment)
.

[vbatts]

#179 is an approach to this.

[laijs]

Any approach that changes json to other protocol would be an endless progress.
It is not a good idea to shift it from json. It is to be hoped that the user-platform-agnostic problem is fixed before 0.2.0

[vbatts]

another part of this is code generation. As mentioned in #185 (comment), it is a goal of having a schema that is language agnostic. /cc @LK4D4

[kofalt]

FWIW, we've been using JSON schemas to great effect (example here). I'd agree their docs are a little wonky beyond a few demos, but there are a lot of options for validation and it seems a well-tread path. It's also convenient that a schema is itself JSON, so you're not mucking about with various formats & protocols.

I don't want to claim that it's the best option for this use case, in fact I'd be interested if there are alternative proposals, but it has yet to bite us in our applications. YMMV.

[vbatts]

see #313

[vbatts]

Thanks for the pointer @kofalt

[vbatts]

@crosbymichael I've added this to the v0.4.0 milestone, as you had added it to #324

[vbatts]

This should be resolved, as #310 is merged. Let me know if this needs further iteration.