Upgrade DBC feeder to new API

SebastianSchildt commented 1 year ago

Remove databroker specific code from dbc feeder, and integrate new kuksa-client python lib.

The resulting feeder shall work with databroker and kuksa.val server

When testing also take care of #28 #19 and #32

romainletendart commented 1 year ago

Should it support ws (VISS) or is it OK to make the new feeder gRPC only?

SebastianSchildt commented 1 year ago

Easy: It needs to support ws.

The rationale is, that we enable more of the ecosystem for databroker, but not regress on existing functionality. "new GRPC only" is only an option once either

val-server supports the new GRPC protocol or
databroker supports all relevant missing features from val-server, potentially obsoleting it (currently there are still a few huge holes, the utter lack of security being one of them)

So the idea of this whole API migration is to make the schism inside kuksa.val smaller not larger/more complicated for users.

If the easy way to achieve this, is still having "two modes" as with the current hack, that would be acceptable I think, if it not boils down to hiding two complete distinct feeders in one project....

SebastianSchildt commented 1 year ago

Adding a potentially relevant comment from @erikbosch from https://github.com/eclipse/kuksa.val/pull/413

In dbc2val we have two DAPR-related configs. I can now understand the usecase for VEHICLEDATABROKER_DAPR_APP_ID, but I do not really see any reason for DAPR_GRPC_PORT, you could as well use the standard config mechanisms for address and port, right?

SebastianSchildt commented 1 year ago

Done in #33

eclipse / kuksa.val.feeders

Upgrade DBC feeder to new API #29