I am not Ramon but I can answer for him here: I am literally about to embark on the task of finishing up the proposal for the ESC types (and then some other types). The total scope of this undertaking is outlined here:
Just had a call with @TSC21 , @PetervdPerk , @dagar where Nuno suggested that we describe the scope of the current effort on the forum so that we could use it as a guideline. This is the post for that. I suggest that we also use this thread for posting the notes from our weekly sync calls.
The text below is a slightly redacted excerpt from a statement of work that Zubax & Auterion have agreed upon. If you spot anything missing, please post a reply.
This document uses the term “master node” for…
Up to now, I was working on these things, which are also necessary for DS-015 although we did not mention them in the plan:
master ← beta-2
opened 01:59AM - 11 Sep 20 UTC
Fixes https://github.com/UAVCAN/specification/issues/90
Context, motivation, … discussion: https://forum.uavcan.org/t/data-type-extensibility-and-composition/827
Implementation: https://github.com/UAVCAN/pydsdl/pull/45; its documentation: https://pydsdl--45.org.readthedocs.build/en/45/
-----
This is the last PR separating us from v1.0-beta; you will notice that I have renamed the document into "**Specification v1.0-beta**" in this branch already.
The changeset is large because it required updating many independent sections of the document. I recommend reviewing it by simply reading chapter **3 DSDL**, without any regard for the diffs. Afterward, the second pass can be done by looking at the diffs only.
There are some inconsequential changes in the script `render_dsdl.py` that are safe to ignore. This script is seriously getting out of hand and I wish someone could rewrite it using a proper template engine like Jinja. I never expected it to grow so complex.
I also removed the term "data schema" from the spec because it did not reflect the reality accurately and was used incorrectly in several places. Instead, we now use "data type". This change made it painfully obvious that service types should not even belong in the category of serializable types because they are not serializable, but I suppose we'll not be changing this detail now unless someone is willing to volunteer.
master ← beta
opened 11:52PM - 14 Sep 20 UTC
- Update CI to Ubuntu 20.04, GCC 10, Clang 10 (also fix a couple of minor nitpic… ks from the new clang-tidy)
- Implement https://github.com/UAVCAN/specification/issues/94
- Implement https://github.com/UAVCAN/specification/issues/90
- Fix the NaN handling issues discovered by Scott in https://github.com/UAVCAN/nunavut/pull/115
- Bump the version number to **v1.0**. A long way from the first commit https://github.com/UAVCAN/libcanard/commit/6d7d39eae1d399da9bb4f62e292a5e70cbffd75d pushed in 2015.
This PR will not be merged and may incur changes until https://github.com/UAVCAN/specification/pull/97 is approved.
I debated whether it's worth [renaming "subscription" into "listener" to avoid confusion](https://forum.uavcan.org/t/how-to-use-services-correctly-in-libcanard/927/2?u=pavel.kirienko):
> In Libcanard, there is a bit of an implementation-specific terminology mishap: it uses “subscribe” in the sense of “tell the library that the application wants to receive this kind of transfers”; the mishap is because I couldn’t find a better word to use. Maybe I should have used “listen” instead, like canardRxListen? I wonder if we should change it.
In the end, I decided to not change it, keeping the old verbiage. If there is interest, it's not too late to do it now.
FYI @TSC21 @PetervdPerk-NXP @dagar
**EDIT:** it's worth noting that despite the subject-ID range review, this changeset does not render Libcanard v1.0 wire-incompatible with v0.100, excepting fringe cases of low importance. This is because the compatibility implications have been taken into account by https://github.com/UAVCAN/specification/pull/96.