Open erikbosch opened 4 months ago
Not using it.
Feature that comes to mind we want in the new API is "streaming set for providers", but we have known for a long time, just never came around to do that. Also I think this is often not a short term deal breaker for migration, because switching before having it "just costs performance".
On thing that can't easily be "ported" (except just "renaming") is the SQL query feature. But I would almost consider that a separate API, and IF we want it, treat it more like such, as we do e.g. with VISS: If you want it, you need to enable it at compile and/or runtime
As of today Databroker support two APIs:
kuksa.val.v1
is the newer API, but does not support all features of the oldersdv.databroker.v1
API, and we have said thatkuksa.val.v1
might be extended to include more features, but there has not been much progress lately. But it is not really clear what needs to be "migrated" in order to be able to deprecate and later remove the old API. For this we would need some inputsdv.databroker.v1
?kuksa.val.v1
API?sdv.databroker.v1
so that we if possible can find alternative solutions with or without extending the new API.If you use the
sdv.databroker.v1
API, please let us now by commenting this issue.