The uavcan/cyphal duality is considered harmful:
On the other hand, the possibility of renaming the uavcan namespace into cyphal raises backward compatibility concerns:
Do we want to explore the possibility of safe renaming to minimize the confusion and make the technology more approachable?
An alias, using or import ability would help but could open the door to some abuse. Each language can already do some of this except C, which would have to make a bunch of macros. Would this be pulled into the dsdl then use language features to replicate?
I think at the language level this can be addressed in a rather straightforward manner, even if it requires special casing within Nunavut (e.g., alias everything as you suggested).
We should rather be concerned about the wire compatibility issues. For example, old nodes follow the current register naming format uavcan.(pub|sub|cln|srv).PORT_NAME.(id|type), uavcan.udp.iface, etc.; while after the renaming the format will switch to cyphal.(pub|sub|cln|srv).PORT_NAME.(id|type), cyphal.udp.iface, etc. This affects, for example, Yukon, which expects special registers to have the uavcan prefix, but as we control Yukon, we can easily implement the required mitigations. The important question is: are there applications out there that will be adversely affected by this change?
Precompiled DSDL for 107-Arduino-Cyphal would need to be recompiled, the changed namespace would constitute a breaking change for all applications that already leverage it.
That being said, I’d consider this proposal a “worthy” breaking change.
Another exhibit:
I think this is a bit of a non-starter unless we can do this in a phased manner where both are supported for a time.
Another thing that might actually help with the problem I was discussing the other day (i.e. that the number of optional types in our public, regulated set are daunting) is to keep only the most fundamental types as uavcan. For example, Heartbeat and GetInfo and the types they depend on would remain uavcan but everything else would change?
This would require a lot of duplicated code, but what if we had a uavcan and a cyphal namespace in the public_regulated_data_types repo. That way, people who are still using UAVCAN can continue to use the uavcan namespace and people using Cyphal can use the cyphal namespace.
Another option is what if we left the public_regulated_data_types repo alone and made a new repo called cyphal_public_regulated_data_types.
Neither of these options are very clever, but might be the most straightforward.
This strikes me as a dangerous half measure.
DSDL: Either a hard cut or dual support forever. Devices that are already in the field are unlikely to update to the cyphal namespace anyway.
Tooling on the other hand should support both namespaces for quite some time (possibly forever).
There are two aspects: renaming the DSDL namespace itself and renaming the registers.
The DSDL renaming can be done by copying all non-deprecated definitions from the uavcan namespace into cyphal with the appropriate changes to the documentation where the original namespace is referenced. All uavcan.* definitions will be made @deprecated immediately, with their complete removal deadline set somewhere in the future.
The standard register names will be updated from uavcan.* to cyphal.*. Nodes will be encouraged to support both to enhance compatibility with old tooling, but we don’t want to unnecessarily burden new applications with supporting the legacy register naming scheme, so uavcan.*-named registers will be optional, and the new cyphal.* pattern will take precedence.
The latter change will make new nodes incompatible with the existing tooling, such as Yakut and Yukon. This is easy to address at this stage as these are the main Cyphal tools and we can implement the necessary adjustments fairly easily. In particular, Yakut/Yukon will attempt to query cyphal.* registers first and only fall back to uavcan.* if none are found.
I think this is sensible as long as we make it clear that the uavcan namespace is deprecated and is on its way toward its inevitable EOL.
Indeed.