Changing submodule reference to use new repo

eclipse-kuksa / kuksa-python-sdk

The Python SDK for Eclipse KUKSA

Apache License 2.0

3 stars 5 forks source link

Changing submodule reference to use new repo #23

Closed erikbosch closed 2 months ago

erikbosch commented 3 months ago

Use proto files from kuksa-databroker instead of kuksa.val

This should not make any practical difference as the files as of today should be identical

erikbosch commented 3 months ago

Hmm, noticed that test fails as

Kuksa Server JWTs does not exist in kuksa-databroker or kuksa-common
Kuksa TLS certs exists in kuksa-common, but we have previously discussed if we should remove them as "default"

We have said that KUKSA Server shall reach EoL 2024-12-31, but we have not yet said when we should remove KUKSA Server support from kuksa-client. I see some options:

Remove default certs/tokens from kuksa-client. This we have talked about before as a preferred solution.
Continue to use kuksa.val as that is the only place that contains default tokens for KUKSA Server (Default TLS certs exist in kuksa-common as well)
Skip submodule dependency and instead use copy/patse

Thoughts @SebastianSchildt ?

SebastianSchildt commented 2 months ago

Not sure what the best course of action is, but I thing removing support in python-sdk for val-server could be done immediately, as we still do have released, working versions for val-server out.

The only point is, that this library also works with the VISS "dialect" of databroker, but going forward, I don"t think supporting VISS and GRPC in one library makes sense (especially since API differences can not be hidden, and the current "threaded" API, supporting both, is an ugly compromise). So I would not hink it is worthwhile t kepp that ability (as for "VISS", rather make a nice Node.red Flow in incubation, or see whether the COVESA CSDP webclient works)

erikbosch commented 2 months ago

So then it seems @SebastianSchildt that there is no problem to start by removing default TLS/Token, then we can as a second step decide if we should remove Websocket support or not

erikbosch commented 2 months ago

Updated now but should do some more tests

erikbosch commented 2 months ago

I have tested pypi package and docker containers, things seems to work. Work might be required in downstream projects if they in test or documentation rely on that tokens/keys/certificates are available locally and default values exist.