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);
