Use server without client

[susuhahnml]

Motivation

In some cases people might want to use the clinguin server but not the client. This are cases where they want to create their own UI without using ASP but they require the information provided by the clinguin backends (cautious, brave etc). They also want to have the operations available in clinguin. We have seen this in Siemens Configuration and in Study Regulations

How can we facilitate this?

• We would need to document how to use the clinguin server as a REST API. What are the available operations and the response structure.

Proving the information

Option using UI

• Out of the box they could create a mock up UI file that they use in they own front end. This UI file would have to somehow gather all the information of the domain state using elem, attr, and when.

• This would allow us to provide something like a clorm classes to handle this.

• Is not nice, it requires extra work to write a UI encoding with wrong semantics

Option responding the domain state

• The UI file could be optional, or just have a window so that it is ignored without throwing issues
• We could respond also the domain state in the request
  • It would have to have some sort of format. How do we write the domain state as a JSON?
  • Alternatively, we can just add it as a string with all facts and the developer can handle it as then wish.
  • Maybe there is some other smart/nicer way to write all this that is easier to access by the new frontend.

The response could look like this:

{ "ui": "<old response with the hierarchical UI>",
"domain_state": "<see ideas below>"}

Idea 1 of possible response as JSON

{
"_any":["a","b","c"],
"_all":["a"],
"model":["a","b"],
"_clinguin_cost": 10,
"_clinguin_browsing": true
}

To get this output, each domain state constructor should know how to create a JSON and not only a set of facts.
It involves changing the current arquitecture and implementing something for each construct.

Idea 2 of possible response as JSON

A simple version that does not involve changing the current architecture

{
"_ds_brave":["_any(a)","_any(b)","_any(c)"],
"_ds_cautious":["_all(a)"],
"_ds_model":["a","b"],
"_ds_opt": ["_clinguin_cost(10)"],
"_ds_browsing":["_clinguin_browsing"]
}

Not so pretty but can be implemented easily