feat: add initial requestThingDescription implementation #1166
Conversation
JKRhb
requested review from
danielpeintner,
egekorkan,
relu91 and
sebastiankb
as code owners
JKRhb
force-pushed
the
request-thing-description
branch
from
5a267b6 to
cd96956
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #1166 +/- ##
==========================================
- Coverage 76.67% 76.33% -0.35%
==========================================
Files 80 80
Lines 16625 16827 +202
Branches 1603 1616 +13
==========================================
+ Hits 12748 12845 +97
- Misses 3847 3952 +105
Partials 30 30 ☔ View full report in Codecov by Sentry. |
relu91
left a comment
relu91
left a comment
There was a problem hiding this comment.
I would fix Ege's point and I left a couple of comments below. Moreover, I wondering if we can somehow track the different TODOs comments before merging. Maybe when we reched two accepts we can create the issues and do a quick update of the comments with a link to the issues? Finally, maybe I missed why there is so much discrepancy between coaps and coap implementation?
JKRhb
force-pushed
the
request-thing-description
branch
from
e4fad1f to
3a7c741
Compare
That is actually because we are currently using two different libraries for CoAP ( |
danielpeintner
left a comment
danielpeintner
left a comment
There was a problem hiding this comment.
I think for an initial implementation it is fine as is.
I added some comments below
relu91
left a comment
relu91
left a comment
There was a problem hiding this comment.
Good enough for now. Let's improve it with future iterations!
4 participants
This PR adds an initial implementation for the
requestThingDescriptionmethod.The implementation details probably still need some additional discussion – looking forward to your feedback here :) For now, I extended the
ProtocolClientinterface with a newrequestThingDescriptionmethod that is expected to return aContentobject that is deserialized and (supposed to be ) validated by theWoTimplementation.I think this latter part also touches #1055 – in my opinion, there should be some validation happening so that library users can be sure that they always receive a valid Thing Description. Maybe the algorithm(s) in the Scripting API would need to be adjusted then as well.
For now, I only implemented the protocol-specific
requestThingDescriptionmethod for HTTP and CoAP, if the general design works for you more protocols could be added in follow-up PRs.