Documention on qua-compliance is not complete

[achirkin]

Here are some things I found after quick browsing:

1. The text in Metadata section does not correspond to an example above,
2. I could not find specification of contraints. Did you add it to the doc?
3. Input section contains only obligatory inputs, but no service-specific parameters in a format we discussed (for strings- enumeration of variants, for ints - some other form). As I remember, we had following options: string, number, bool/
4. All listings have geomID key, which is wrong. They should have ScID key for scenario id.
5. Listing 8: output should not have key points. It should have two attachments: objIds ibjVals. Or maybe only latter one.

[mtfranzen]

Could you clarify point 3? Most issues are fixed here: https://github.com/mtfranzen/qua-kit/commit/65fa456300bff820eb2ee82aa73e803041d04299

The whole constraint-stuff was kind of hidden in the meta-data section. I think it is now more clear :)

[achirkin]

Thanks a lot! Why don't you push directly to here? Please, do it next time :) 3: We discussed that all qua-view-compliant services must have a number of parameters depending on their mode. However, all of them may have configurable optional parameters, subject to some constraints - that allow to render these parameters in qua-view. For example:

1. Any number of {"key name":string} pairs, which have to have corresponding constraint that contains a list of possible strings (enumeration)
2. Any number of {"key name": bool}.

In general, the section lacks well-structured detailed information regarding how to declare a proper remoteRegister message, which will make it super-difficult for a third party to implement a proper service. I would suggest to add first an overall scheme of the remote-register and corresponding request message, and only after that all the examples you made.

Anyway, thanks a lot for contribution! If you don't have time for this, I will do it on my own later some day.

[mtfranzen]

A short introduction how to register a service in Luci is given in Section 2.1, but yes, the optional root-level-arguments are missing here. I will give more details (and a listing) in this section and then reference it in the section QUA-Compliance. Maybe I restructure the section as a whole :)

Will try to wrap this up in the coming days and make a pull request!

[achirkin]

Updated this section in the latest commit with significant changes in format. Still, I do not close the issue -- could you please skim though it, and also finish the last subsection of this section?

[mtfranzen]

Added a description and made some minor changes to the example. One thing, I'm unsure about: In the scenario-execution-mode, your examples have the output fields "answer" or "image". That means we should probably change the output fields of the example service from

XOR values XOR value

to:

OPT values

right?

[achirkin]

Yes, you are right! Also, I think, we should change mode objects: objIds to geomIDs, because in the luci definitions there is a unique property geomID:long for each object. Then names will look more consistent, I guess.

[achirkin]

Ok, I fixed most of things I could find. Pull before continuing to work on the spec!

[mtfranzen]

This issue can be closed right?

[achirkin]

Not sure now :) can you skim through it and adjust if needed and then close?

[mtfranzen]

Yep, will do!

On Thu, Feb 2, 2017 at 7:03 PM, Artem M. Chirkin [email protected] wrote:

Not sure now :) can you skim through it and adjust if needed and then close?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/achirkin/qua-kit/issues/1#issuecomment-277034217, or mute the thread https://github.com/notifications/unsubscribe-auth/AASX-p55GB44QBVUo9Zv4VHzIzJSLbG0ks5rYhqPgaJpZM4KhDaV .

[achirkin]

Not sure, what was the last state of this? :)