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