-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VISS Base vs. Extensions #385
Comments
What would be the merits of a special syntax in this case. I think it is pretty clear what is optional and what is not ? You just add optional to the paragraph ? I my view this is overcomplicating things. |
Marking things as "optional" (or/and mark "core/essential") definitely is the most important step. In my opinion an important point and takeaway from Erik's suggestion is, that our model should be: There is "base/essential" required feature level, the rest are understood as "features" that can be (more or less) mixed and matched as people require (which is in line with the RISC V ISA model), and not a set of "Feature Level 1,2...3" where every level bundles a fixed amount of features. That would lead to endless discussions :) Probably the market will show what are useful "feature sets". For practical purposes it might be useful to have something like a "capabilities" query, which returns a nicely formatted JSON or text string listing supported features in a machine readable way.. |
Syntax is maybe not the right wording, I was more thinking if it would make sense to have some form of identifiers for the optional parts/capabilities, so that you cay something like "Our product X supports the following optional capabilities from VISS: AAAA, BBBB and CCCC, but not DDDD". But the section headings of the optional parts could possibly suffice for that purpose. |
I agree with what has been said above. So the next step would then be to
I would propose that 2. is solved by using the "static metadata" request that the spec supports (CORE ch 7.4), by adding |
Fixed in PR#437 |
In #381 and #382 it is discussed if certain parts of VISS should be optional. Would it be an idea to have a generic concept/syntax where certain parts of VISS can be specified as mandatory (base functionality) while others are specified as optional extensions. Somewhat similar to https://en.wikipedia.org/wiki/RISC-V#ISA_base_and_extensions
That could possibly be useful for the future when organizations start offering VISS implementations to possibly customers (both clients/applications and server-solutions) to have a common language to describe what is supported. E.g. a syntax to specify that a VISS server implementation for example supports Authorization and PathFilter but not CaptureFilter
The text was updated successfully, but these errors were encountered: