You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Alan Carvalho de Assis <ac...@gmail.com> on 2020/06/02 19:23:07 UTC
Re: api stability in apps/netutils/webclient
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 <ya...@midokura.com.invalid> wrote:
> hi,
>
> On Fri, May 29, 2020 at 11:53 PM Sebastien Lorquet <se...@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 <sp...@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);
>
Re: api stability in apps/netutils/webclient
Posted by Sebastien Lorquet <se...@lorquet.fr>.
Hello,
I have introduced nxcurl as a simplified curl for NuttX. It is a real
port, only the function names are different.
The interface is similar to the real curl.
It is not abandoned, the implemented features work.
IIRC it supports what is required for reimplementing webclient on top of
it. If it was broken in the apache transition mess, it's not because of me.
The name is weird, but it can be renamed if that helps anyone. Meanwhile
a trivial header file can rename functions.
I use it in an internal unpublished project. I have only implemented
what was required, but it works well.
If anyone requires extension, like the multi api, you are welcome to
provide patches. I can review them.
Sebastien
Le 31/07/2020 à 06:38, Takashi Yamamoto a écrit :
> On Wed, Jun 3, 2020 at 4:23 AM Alan Carvalho de Assis <ac...@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 <ya...@midokura.com.invalid> wrote:
>>> hi,
>>>
>>> On Fri, May 29, 2020 at 11:53 PM Sebastien Lorquet <se...@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 <sp...@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);
Re: api stability in apps/netutils/webclient
Posted by Takashi Yamamoto <ya...@midokura.com.INVALID>.
On Wed, Jun 3, 2020 at 4:23 AM Alan Carvalho de Assis <ac...@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 <ya...@midokura.com.invalid> wrote:
> > hi,
> >
> > On Fri, May 29, 2020 at 11:53 PM Sebastien Lorquet <se...@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 <sp...@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);
> >