Consolidate Workspace Config format

NOTES:

• content type serializing WSConfig is out of scope, we can imagine other than JSON (for instance YAML) as an alternative.
• serialization mechanism and accessibility are out of scope as well. We can imagine storing WSConfig anywhere (DB, local file etc) and keep it locally or remotely (accessible via http using URL for ex)

Context: For the time we have several formats and mechanisms to start Workspace such as (Factory, Stack, Chefile) which extends WorkspaceConfiguration to add additional automation ability and semantic. I suppose for the time being we have enough experience to formalize consolidated model of WSConfig which would add “useful” metainfo from Factory and Stack definition and so remove different evolution branches of it and in perspective retire other formats from the Che core model.

Proposal It is proposed to extend it adding two top-level objects:

• tags (inherited from stack)
• ide (inherited from factory)

config: {
  name: "",
  description: "",
  defaultEnv: "",
  environments: {},
  projects: {},
  commands: {}
  tags: [],     --  from stack, things like "java", "maven", "sample" etc
  ide: {}        --  from factory, things like handlers for IDE app events etc
}

[garagatyi]

+1 to consider removing multiple environments.

yes, it is in our factory format but usefulness is doubtful, do you have some arguments?

We have those features in factory. If we remove factory concept then either we move those features to WSConfig or declare that they are not needed anymore.

Not sure I understand. If it is expected that IDE (for example) opens the same file on loading - then yes it should be the case (thats what factory does). If it is not needed (which is the case for 99%) then no actions should be configured.

If we remove factory object and use stored WSConfig instead than configured onOpen action IS useful on WSConfig applying, but might not be useful or even bad for UX in case applied WSConfig is used continuously. Am I correct that this issue suggests removing factory object?

[gorkem]

@gazarenkov do you think we can close this one now