Terminology

Feeder vs Provider

Excerpts from chat (5th December):

Let's start with the term feeder. The directionality of the word immediately becomes an issue when trying to apply it to the things we want to have names for in our software.

Feeder
It's feeding something.

To give a common example, you can feed a child or you can feed an animal. If it's your job, then you are an animal feeder. In our case, the feeders are only ever feeding kuksa-val-server or databroker, i.e. they are kuksa.val feeders. So far so good.

So how are we naming things now then? We have a CAN feeder and a GPS feeder. Sounds like something that is feeding CAN and another thing feeding a GPS, i.e. CAN and GPS is the destination.

The same logic applies to a sensor feeder or actuator feeder. It's conveying the wrong direction. And this becomes even more evident when we are actually "feeding" stuff for example in the CAN direction.

So let's compare it to a provider.

Provider
It's providing something.

It can provide us with

• Actuator(s)
• Sensor(s)
• Attribute(s)

It would also make perfect sense for an actuator provider to provide us with a way to actuate it. And it would be equally logical that it would provide use with readings of it's current value (i.e. acting as a sensor provider basically).

Furthermore, it also makes sense to have:

• SOME/IP provider
• CAN provider
• LIN provider

since they are providing us with gateways into these protocols.

They can themselves also act as (VSS) actuator providers and (VSS) sensor providers.

Provider just seems like the the right thing to use.

--

But terminology matters. It will be reflected throughout the software we write and the APIs we create. Confusing terminology leads to confusing software and confusing APIs.

If we get the terminology right, a lot of things will naturally just fall into place. And I think using "providers" or "signal providers" in terms of the VSS model and kuksa.val is one of those cases.

Using terminology like:

• Provider
  A provider is providing a signal (sensor, attribute or actuator) to the VSS tree.
  A provider can also use signals as any other user.

• User
  A user (or client) is using the signals in the VSS tree (without providing any of them itself).

instead of, for example:

• Northbound App
• Southbound Feeder
• Southbound Service

will make it a lot easier to reason about our software and explain it to others.