First draft of terminology

[SebastianSchildt]

This is a first stab at defining the terminology.

Goals was to give definitions usable on "PPT level", that we can then hopfully use consistently accross our repos and documentations. I tried not going too deep on specific technical details and limitations, excpet one or tow sentences here and there (i.e. compared to the discussions in Wiki, I did not mention specific API or auth scopes).

I did a recap of the most important (hopefully) VSS terms. @erikbosch : You are likely a good authority to check here. I did a lot of copy & paste though :)

Some things I was not sure about is in bold. Main things is "Client"/"User"/"App"

One thing which I do suggest, is a differentiation between "sensor-provider" and "actuator-provider", because I feel it makes a big difference in system design "southbound" of us, even though for databroker not much difference. Rational here is, if we switch over to the term "provider", as a "better way of saying feeder", I think it would not be good to have a dbc-provider (as in current feeder), and a seat-provider (as in current service), without being able to have a clear/definend way of saying what they are doing (in that sense dbc would clearly be a sensor-provider, while seat would be an actuator-provider (if we use the VSS defintion of every actor is also a sensor) or both)

[SebastianSchildt]

I changed state-provider to data-provider and integrated all other comments. Also fixed a number of typos. Content-wise I would consider this ready now

[argerus]

I think we should drop the "VSS" from Client and Server, since their client / server relationship has nothing to do with VSS. It would be perfectly possible to have VSS providers that acted as servers, with KUKSA.VAL server/databroker acting as a client of those while still acting as a server for other clients.

I do think it makes sense to keep the VSS prefix for VSS Consumer and VSS Provider, as that describes their relation with regard to VSS and is independent of the network architecture of the implementation.

So something along the line of:

           ┌───Client─────┐
           │              │
           │ VSS Consumer │
           │              │
           └──────────────┘

 ┌───Server────────────────────────┐
 │                                 │
 │                                 │
 │                                 │
 └─────────────────────────────────┘

┌───Client─────┐ ┌───Client──────┐ ┌───Client───────────┐
│              │ │               │ │                    │
│ VSS Provider │ │ VSS Provider  │ │ VSS Provider       │
│              │ │               │ │                    │
│              │ │ data-provider │ │ actuation-provider │
└──────────────┘ └───────────────┘ └────────────────────┘