Hello, Le jeu. 26 avr. 2018 à 09:17, Daniel Stenberg <dan...@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
