VSC properties - always read/write?

[erikbosch]

In the README properties no longer has a type field, but it is still present in the seat example service:

    properties:
      - name: a_property # Will this be acceptable?
        description: A signal
        type: attribute # or sensor.
        datatype: uint8 # Native datatypes only?

In the README it says:

Each properties list object specifies a shared state object that can be read and set, and which is available to all subscribing entities.

So is the current intention that properties always shall be considered to be read/write in VSC? Or do we need extra information to cover that? Either like in the example using VSS terms (attribute/sensor/actuator), or by other means like writeable: true

[erikbosch]

Overlaps quite a lot with #75

[erikbosch]

@gunnarx @magnusfeuer-mbition @magnusfeuer

I think this one would be quite good to bring up on the next meeting. Both related to the long term discussion of integrating/importing VSS into VSC, but also for the reason that many other languages have mechanisms to specify if an attribute (or similar concept) is read-only or read-write. So do we need a mechanism to specify that in VSC as well?

[gunnarx]

Since this is a question for the definition of the language/interface-model that is now IFEX project, the issue will be transferred from Vehicle Service Catalog project to IFEX project.

[gunnar-mb]

So is the current intention that properties always shall be considered to be read/write in VSC? Or do we need extra information to cover that? Either like in the example using VSS terms (attribute/sensor/actuator), or by other means like writeable: true

Yes, but that metadata should probably be handled by a layer.

In some cases an interface might be clearly designed to make some properties read or write-only in every situation, and this might be useful to communicate as part of the pure interface description*

But in most cases I think it is a question at deployment time whether a property shall cause the generation of such functions as get<property>, set<property> and subscribe<property>. Thus it is likely to be specified, per each property, in a Deployment Layer. In addition to this, there are often cases when access-control applies. In other words some clients are allowed to write, others only to read. That also needs to be handled in an additional layer that handles access-control rules, to keep it separate from the pure interface description.

*So for the few cases that remain, where it would be truly useful for the interface designer to state that a property is intended to be only read or only written (in all future usage of the interface description), then I am leaning towards that it might be OK to not give explicit support in the IDL nonetheless. (Support using a layer definition is of course still possible).

One special case to ponder is the idea of a "constant value" (only reading makes sense for constants, of course). There's no explicit design for that yet, and this topic is worth a bit more consideration. Open for feedback.

[gunnar-mb]

In the README it says:
Each properties list object specifies a shared state object that can be read and set, and which is available to all subscribing entities.

That text was carried over to the description of Property in the model (ifex_ast.py), so it should probably be reviewed to make it clearer and avoid misunderstandings. The existence of get/set/subscribe is actually decided during deployment, and "available to all subscribing entities" should be understood as applicable only entities that are allowed to subscribe (through whatever access-control strategy is used). This might need clarification. Open for suggestions of new descriptions.