Re: CoAP support in libcurl for the Internet of Things
Date: Mon, 07 May 2018 08:31:19 +0000
Le jeu. 26 avr. 2018 à 09:17, Daniel Stenberg <daniel_at_haxx.se> a écrit :
> On Wed, 25 Apr 2018, Remy 'Sieben' Leone wrote:
> First: I love a reply to an almost two years old email! =)
I know you would appreciate it. Same here :-)
> > What would be the best approach to offer support for CoAP in the libcurl?
> How about starting out with "selling" the idea to us? Why do you think
> support in libcurl is a good idea?
CoAP was designed from the get-go to take an approach very close to HTTP.
Verbs, URL, stateless, ...
IoT developpers are using it. You can see a list of implementations on this
> Is there really that big overlap between
> CoAP and the other protocols libcurl supports so that users are likely to
> actually want support for them all in the same library?
I think the command line tool is really useful for instance, you can check
or not your device is working correctly and replying to the right request.
> > - Would you prefer to add support by re-implementing / porting a C
> > inside libcurl? For instance, most of the CoAP code would be ported from
> > libcoap or another C library directly inside libcurl. It would represent
> > significant amount of code to review but would give the advantage to be
> > tailored to fit libcurl requirements.
> There are pros and cons with both approaches. But if the protocol is just
> sufficiently complicated and there are other users of an external library
> could also work for on it, I think relying on an external library is
> preferred. That of course assumes that the library is good and reliable
> enough. I'd hate to build functionality into libcurl that relies on a
> library that isn't trustworthy.
> Using a third party library makes users from other projects who also use
> same library to also have a an interest in having it working and be
> But it also might not make the API super trimmed for us and it might also
> it hard for us to get the changes we want done and get the necessary focus
> "our" issues.
> From the little I know of CoAP, it seems complicated enough for me to say
> leaning on someone else's hard work seems like a good idea.
I think Olaf Bergmann (in CC) did a really great work with libcoap.
Plus I think he got a proof-of-concept implementation for
> > - Would you prefer to simply link to a third party library such as
> > It would mean adding an optional dependency to libcurl build.
> Sure, but it would only be a dependency for those who choose to build with
> that support enabled. At least until we see an increased interest, we
> make the CoAP changes as limited as possible to only affect those who
> enable its support.
> If I would be negative about something, then it is that libcoap is
> badly documented ("here's a link to my doxygen-generated index page, which
> happens to be blank") and I strongly dislike the feeling of not being able
> quickly browse the API to get a sense of how it works.
I think new improvements to the documentation are shipped. Maybe Olaf can
jump in and tell us more about it.
> It is also yet another dependency that relies on its own TLS library,
> seems to mostly be OpenSSL on posix systems.
> libcoap is BSD-2 licensed, which is perfectly compatible with curl.
> libcoap also implements the server-side of the protocol which then
> makes it suitable to also use for creating a test server for the test
> side of things.
> / daniel.haxx.se
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-05-07