Open mgrojo opened 5 months ago
Thanks for letting us know! We will look into this issue.
As part of my master thesis, I have the intention of writing a CoAP library and an application in SPARK/Ada. Using RecordFlux seems thus as a good idea.
Great that you are considering using RecordFlux for this purpose! We took a look at the CoAP message format a while back. As I recall, its creators made some nasty design choices. While we aim to be able to specify all common communication protocols, it may be difficult or even impossible to fully specify all aspects of CoAP with RecordFlux at this stage. We would be very interested in your findings on this endeavor.
We took a look at the CoAP message format a while back. As I recall, its creators made some nasty design choices.
Thanks for the information.
Searching for CoAP in the repository, I've found an issue affecting the protocol (#61) and an attempted implementation in the coap branch.
While we aim to be able to specify all common communication protocols, it may be difficult or even impossible to fully specify all aspects of CoAP with RecordFlux at this stage. We would be very interested in your findings on this endeavor.
Besides the issue with the end markers, are there any other problems that I'll have to face? Does this mean that I could only define a partial model that would require later manual modification after the generation to work around the problems? I assume that, even with the need of some workarounds, the use of RecorFlux versus a direct implementation in SPARK is the best approach. What's your opinion on this?
Besides the issue with the end markers, are there any other problems that I'll have to face?
Another issue could be the special cases for the Option Length field, where there is a separate 8-bit or 16-bit length field depending on the value. Adding separate Option Value fields where the field length is calculated differently for these special cases might be an acceptable workaround.
Does this mean that I could only define a partial model that would require later manual modification after the generation to work around the problems? I assume that, even with the need of some workarounds, the use of RecorFlux versus a direct implementation in SPARK is the best approach. What's your opinion on this?
Modifying the generated code correctly could be very hard and I wouldn't recommend it. I think doing the modifications that are necessary to support a sequence with end marker (#61) could be doable, but it definitely wouldn't be simple. I wouldn't even try to solve the above-mentioned problem with the Option Length in this way.
A workaround could be to use a RecordFlux specification that omits details that cannot be represented and implement a manual parser for these parts. For example, you could use an opaque field for the Options | Marker | Payload
part in the RecordFlux specification and use a manually implemented parser that parses an Option and checks if the Marker is present before parsing the next Option. For the actual parsing of a single Option, you could still try using a RecordFlux generated parser. This approach might be a viable workaround if you plan to interact with the generated message parsers/serializers with manually written code anyway.
Thanks for all the information. I'll take all of this into account when I start the implementation.
As part of my master thesis, I have the intention of writing a CoAP library and an application in SPARK/Ada. Using RecordFlux seems thus as a good idea.
After trying to use
rflx convert iana
for getting the conversion of number resources from the IANA specification for CoAP, I've got an exception in the tool.Steps to reproduce
.venv/bin/rflx convert iana core-parameters.xml
Result
Workaround
After a bit of debugging, I've seen that removing this node in the XML, the exception is avoided and the rflx code is generated.