Hello,

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
> CoAP
> 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
site:
http://coap.technology/

> 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
whether
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
> library
> > inside libcurl? For instance, most of the CoAP code would be ported from
> > libcoap or another C library directly inside libcurl. It would represent
> a
> > 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
> that
> could also work for on it, I think relying on an external library is
> usually
> 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
> single
> library that isn't trustworthy.

> Using a third party library makes users from other projects who also use
> the
> same library to also have a an interest in having it working and be
> stable.
> But it also might not make the API super trimmed for us and it might also
> make
> it hard for us to get the changes we want done and get the necessary focus
> on
> "our" issues.
>
> From the little I know of CoAP, it seems complicated enough for me to say
> that
> 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
curl/libcoap-integration.

> > - Would you prefer to simply link to a third party library such as
> libcoap?
> > 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
> should
> make the CoAP changes as limited as possible to only affect those who
> actively
> enable its support.
>
> If I would be negative about something, then it is that libcoap is
> seriously
> badly documented ("here's a link to my doxygen-generated index page, which
> btw
> happens to be blank") and I strongly dislike the feeling of not being able
> to
> 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,
> which
> 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
> probably
> makes it suitable to also use for creating a test server for the test
> suite
> side of things.
>

Best regards

Rémy

> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-05-07