Clarify VSS expectations on read/write #796
Conversation
I ended up in a discussion of what "doing a read" in VSS means. In short, as of today that we say that a read returns actual value. This PR suggests to change the wording somewhat, so that a read unless otherwise specified shall return the actual value. I.e. it is not forbidden by VSS (project) to have a read-function that returns the desired value instead, but then that must be clearly specified in the corresponding implementation specification. Signed-off-by: Erik Jaegervall <erik.jaegervall@se.bosch.com>
There was a problem hiding this comment.
Looking good to me. It is not "strictly" VSS (i.e. a user might doe "whatever" or in a Non-API system this does not even apply), but there where words to this effect before and maybe now it is more clear what the best - or at least common - practice is.
It is also not contradicting what VISS or KUKSA is doing, just to name two "VSS users" I am aware off.
|
MoM:
|
There was a problem hiding this comment.
Some changes were suggested. Please check them out.
As a side note: VSS specifies the properties (e.g., Speed) and not the actual sensors or actuarors (e.g., speedometer). From that point of view, I agree that it is all about reading and/or writing the associated value of that property. Defining the type as one of sensor, actuator, or attribute is simply a flag that is hopefully considered by whoever implements the interface. We should consider changing the names of this flags at some point to something that is more data-oriented.
Co-authored-by: Daniel Alvarez-Coello <8550265+jdacoello@users.noreply.github.com>
Signed-off-by: Erik Jaegervall <erik.jaegervall@se.bosch.com>
Signed-off-by: Erik Jaegervall <erik.jaegervall@se.bosch.com>
|
Failing DCO check is due to accepting changes in UI, will be fixed by squashing when merging |
|
MoM: Merge |
I ended up in a discussion of what "doing a read" in VSS means. In short, as of today that we say that a read returns actual value. This PR suggests to change the wording somewhat, so that a read unless otherwise specified shall return the actual value.
I.e. it is not forbidden by VSS (project) for implementations to have a read-function that returns the desired value instead, but then that must be clearly specified in the corresponding implementation specification.
This shall not impact VISS/VISSR.