On Wed, 25 Apr 2018, Remy 'Sieben' Leone wrote:

First: I love a reply to an almost two years old email! =)

> 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? 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?

> - 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.

> - 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.

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.

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