-
Notifications
You must be signed in to change notification settings - Fork 2.1k
coap: Replace COAP_CT_ with COAP_FORMAT_
#10108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
smlng
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(minimal) tested ACK
|
one thing: isn't this somehow an API CHANGE? Some RIOT external APP could use the old defines, right? |
Yeah, that's why I mentioned it in the opening post. If everybody nicely based their applications on our examples it should not be a problem, but that's a huge if there. Anyway, I'm fine with this being considered an API change. |
|
I guess it's good to have the label for documentation and release changelog creation. |
|
though I'd like to have second ACK on this one then, too |
Fair enough
Agreed Thanks for the review! |
kb2ma
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing this issue, @bergzand! The COAP_CT_xxx constants predate the merge of nanocoap and gcoap, and I agree it's time to disable these. I also agree it's worthwhile to consider existing users of the COAP_CT macros, although I expect there are few of them.
So, does it make sense to mark the COAP_CT_xxx macros as deprecated for a couple of releases? I would like to see us get into this mechanism for nanocoap/gcoap as the API will be evolving for function names. For example, coap_put_option_ct() (with the same problem as these macros) should change to coap_opt_put_format() or something like that. So, it makes sense to me to deprecate the current function name for a while.
Besides that, this work tests fine for me.
I'm +1 for adding a |
|
Restored the removed defines and added a |
|
Thanks, @bergzand. The deprecated tag really stands out in Doxygen. This all looks good and tests fine for me. There are a few uses of the "deprecated" tag in the code base. I don't know about historical use though. So, I would like to merge this PR, and then I plan to send create an RFC Issue to confirm there is no concern with this approach systematically for evolving the gcoap/nanocoap APIs forward. It helps to have an example. :-) @smlng, any concerns? If not, I'm ready to squash and go. |
|
Link is an improvement (thanks @miri64), and bold looks even better. Unfortunately the use of black color for text means it doesn't stand out as a link. |
Yeah, also noticed that, not sure if we can fix that without modifying the css file. |
|
Looks good to me, please squash |
f4547c5 to
43bdf4e
Compare
43bdf4e to
d76cf06
Compare
Replaces all occurences of COAP_CT_.* with COAP_FORMAT_.*
COAP_CT_ style defines for the content types are deprecated in favour of COAP_FORMAT_ style defines. COAP_FORMAT_ is expanded to include any missing content type that was available with COAP_CT_.
d76cf06 to
8ee2bc5
Compare
|
Squashed and rebased. I've reworded the second commit message to better reflect the current changes. |
|
@bergzand you broke the core 😉 I'll rerun Murdock |
|
I saw the build failure. What went wrong? Also, and this is drifting off topic, but when is it appropriate to tag with 'run tests'? I looked around yesterday for more background, but could not find an answer. |
But how...? |
|
@bergzand I was joking, I think the test is flawed or at least not deterministic in results on native |
|
Thanks everyone for talking this through and improvements. |
|
Now we only have to remember to actually remove the defines in a release or two :) |
At some point we need to go through this list anyway and start removing stuff ;-) |
|
Great! Thanks so much to everyone involved!
+1. There could be some kind of automation between releases :) |
|
I think letting some bot remove stuff from our code is something that would lead to desaster. |
|
(also the interval deprecated should be removed is something that should very much be decided on a case-by-case basis) |
|
Thanks all for the comments! I plan to post a deprecation RFC in the next few days, and will look for consensus on a trial approach to this workflow. BTW @miri64, I know I have seen that "Deprecated List" in Doxygen hundreds of times as I click into something else, but it didn't register in my mind that it existed when I looked for existing deprecated code. Thanks for calling that out. |
I mean something to warn that a feature should be deprecated. We could tag the time somehow. |


Contribution description
According to the IANA defines, there is only CoAP content-formats. and no CoAP content types. This PR merges the list of content types into the list of content formats and replaces all
COAP_CT_.*occurences in our code withCOAP_FORMAT_.*. I merged into theCOAP_FORMAT_options because those were more often used than theCOAP_CT_defines.Not sure whether to call this an API_CHANGE, but all example code uses
COAP_FORMAT_, so the old defines "should" not have been used outside our implementations, but if somebody wants to call this an api change I'm fine with it.Testing procedure
A small test to verify that the
.well-known/corestill has content number 40 should be enough here.Issues/PRs references
None