#Full Https Client

19 messages · Page 1 of 1 (latest)

hardy prairie
rapid aspen
#

From your README in the example:

#include "BearHttpsClientOne.c"
This is already wrong. One should never include a source file.

To compile the lib in Linux you can use the following command:
gcc main.c -o your_output.out
Why don't you just provide a CMake file? That way you don't even need to worry about different operating systems, and it's much more convenient and powerful.
Not to mention: I can't even find a main.c file in your project plus compiling your project that way shouldn't even be possible, as it shouldn't contain a main function, so... what's going on there?

For example this file: https://github.com/OUIsolutions/BearHttpsClient/blob/main/src/namespace/request/fdefine.request.c

  1. Why does it have a dot in the file-name. I know it's technically legal, but it's so annoying to read imho.
  2. How can such a file even compile? You don't have any includes, yet use a ton of variables that are nowhere declared. I assume this works because you have a weird include chain where you include .c files, which is wrong as already stated.
    And I can't stress this enough because this is a mistake you make all over the place. So far in your source code I think I've looked at 15 or so files and even files that are clearly supposed to be header and source. You don't have any include guards in the headers and don't have any includes in the source and I'm just there, guessing where stuff is coming from... and yeah, I'm not willing to spend my time like that 🐒

Why does:
bear.request.newBearHttpsRequest("https://example.com"); return a pointer but:
newBearHttpsNamespace(); returns a non-pointer?

hardy prairie
#

about these , its the simple example #include "BearHttpsClientOne.c"

#

I put these , because its more easy for users, but you can make a linkage with.h if you want, (there its a release for it)

#

about these dont compiile , of course it dont, because you need to build the project using my builder

#

read the build from scracth part

#

if you build the roject, you will see that all the importations are done

rapid aspen
#

And it's practically the same for your BearHttpsClient

#

But yeah, the codebase is just way too large for it to be reviewed in it's entirety.
Please pinpoint a few things you'd like for us to look at

hardy prairie
#

just for github, its impossible for you udnerstand the project, at all

#

I would like to know:

#

from the user perspective:

#

the public api, its hard to use , you could make a https requisition easly ? , or took to much time for it

#

from a contributor perspective:

#

could you build the project, the process of builiding was hard ?