On Wed, Jun 3, 2020 at 4:23 AM Alan Carvalho de Assis <acas...@gmail.com> wrote: > > 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.
do you mean the particular api? or its feature set? anyway i can't think of any reason it's impossible for nuttx. in case you are asking if i volunteer to create such a rich framework, no, i don't. (sorry!) > > 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); > >
