Hi Takashi, Do you think it could be possible to create a HTTP REST framework for NuttX similar to Ulfius:
https://babelouest.github.io/ulfius/ https://www.hackster.io/babelouest/http-rest-framework-in-c-for-embedded-systems-d34b0c It should be very useful feature. BR, Alan On 5/29/20, Takashi Yamamoto <yamam...@midokura.com.invalid> wrote: > hi, > > On Fri, May 29, 2020 at 11:53 PM Sebastien Lorquet <sebast...@lorquet.fr> > wrote: >> >> I think the web client could be rewritten to benefit from the curl port >> I started a while a go, which is available upstream: >> >> https://github.com/apache/incubator-nuttx-apps/tree/master/netutils/libcurl4nx >> >> Improving this curl port would benefit any app using it, not just the >> web client. > > i have looked at libcurl4n before i decided to use webclient. > my problem with libcurl4nx were: > > * weird name :-) > * it looked even less mature and incomplete than webclient. > * no users as far as i know. > * "easy" api was not that attractive. i hope it were "multi" api. > * it looked like an abandoned project. (i guess i was wrong on this > point as apparently you still care.) > > btw, is it a curl port? > i thought it was an independent project with a similar api. > >> >> Sebastien >> >> Le 29/05/2020 à 08:23, Takashi Yamamoto a écrit : >> > hi, >> > >> > On Fri, May 29, 2020 at 7:00 AM Gregory Nutt <spudan...@gmail.com> >> > wrote: >> >> >> >>> i want to add some stuff to apps/netutils/webclient. >> >>> for example, >> >>> >> >>> * ability to report http status to the caller >> >>> * ability to add some request headers >> >>> * put >> >>> * other content-type for post >> >>> * tls >> >>> >> >>> a question: how much api stability is expected for this? >> >> Of course we would like the code to be stable in the sense that it >> >> continues to behave correctly; I assume that you would carefully >> >> verify >> >> new features. But I think by stable you are referring to a fixed API. >> >> I >> >> don't think that is necessary either. This is not a standard >> >> interface >> >> and it is not even documented. People using non-standard, >> >> undocumented >> >> interfaces need to accept that they are subject to change without >> >> notice. >> >> >> >> A good explanation in comments of how to get legacy behavior I think >> >> is >> >> sufficient. Do other people agree with that? >> >> >> >>> can i just add extra arguments to wget() etc? >> >>> or should i keep wget() intact and introduce a new set of symbols? >> >> I don't see any problems with extending wget(). We should do that >> >> wisely. Perhaps it would be better if wget took a structure as an >> >> argument rather than a long, long parameter list. I would personally >> >> prefer to see one wget() rather than the old wget() with a new wget2() >> >> which is the same but with different parameters. >> >> >> >> All current usage of wget() should be modified to use any changes that >> >> you make to the interface. I find only examples/wget/ and nshlib/. >> >> Is >> >> that everything? >> > right now i'm thinking >> > 1. introduce something like the following. keep wget() etc as wrappers >> > of this in the meantime >> > 2. once things get stable, inline the existing users of wget() etc in >> > the tree, like examples/wget, one-by-one >> > 3. consider removing wget() etc >> > >> > struct webclient_context >> > { >> > /* request parameters */ >> > >> > FAR const char *method; >> > FAR const char *url; >> > FAR const char * FAR const *headers; >> > unsigned int *nheaders; >> > >> > /* other parameters */ >> > >> > FAR char *buffer; >> > int buflen; >> > wget_callback_t callback, >> > FAR void *callback_arg; >> > FAR const struct webclient_tls_ops *tls_ops; >> > FAR void *tls_ctx; >> > >> > /* result */ >> > >> > int http_status; >> > }; >> > >> > struct webclient_context ctx; >> > webclient_set_defaults(&ctx); >> > ctx.method = "GET"; >> > ctx.url = "..." >> > : >> > ret = webclient_perform(&ctx); >
