Add fortran-curl as dependency and a minimal GET request example

[rajkumardongre]

Add fortran-curl as dependency and a minimal GET request example, also added a simple_get.f90 file in example folder

[interkosmos]

Just a few remarks:

• The method attribute in request_type and response_type should probably be of type integer.
• The status_code in response_type has no default value. HTTP status codes should be added as public parameters. The attribute content_length should be an 8-byte integer, as it is available in Fortran on 32-bit platforms too.
• Some procedure dummy arguments still need proper intent attributes.
• In new_request(), switch case is preferable to if … then … else blocks.
• The function client_get_response should not stop on error but return an error code/message instead.

[rajkumardongre]

Alright, I'll make the required changes

[milancurcic]

Thanks for the PR @rajkumardongre. I suggest also organizing defining the derived types and their related procedures in their respective modules, and use http_client module only to make available the public API, i.e. response_type, http_request, HTTP_GET etc.

[milancurcic]

Just one space around ::, no need for all this whitespace.

[milancurcic]

Here as well, and elsewhere, just one space after commas.

[rajkumardongre]

I suggest also organizing defining the derived types and their related procedures in their respective modules, and use http_client module only to make available the public API, i.e. response_type, http_request, HTTP_GET etc.

Thanks, @milancurcic. So basically, I need to generate four files.

1. request.f90
2. response.f90
3. client.f90
4. `http-client.f90

request.f90 should contain the definition of the request_type along with its corresponding helper procedures. response.f90 should have the definition of the response_type and its helper procedures. Similarly, client.f90 should contain the client_type and its helper procedure. Finally, http-client.f90 will provide access to the public API.

[arteevraina]

Thanks, @milancurcic. So basically, I need to generate four files.

1. request.f90
2. response.f90
3. client.f90
4. `http-client.f90

request.f90 should contain the definition of the request_type along with its corresponding helper procedures. response.f90 should have the definition of the response_type and its helper procedures. Similarly, client.f90 should contain the client_type and its helper procedure. Finally, http-client.f90 will provide access to the public API.

Yeah, Looks good. But maybe use snake_case for naming http_client.f90 as well ?

[milancurcic]

@rajkumardongre check the recent fpm module and source naming requirements: https://fpm.fortran-lang.org/en/spec/naming.html

Because the default __ thing is kinda ugly, we may want to use a custom prefix (https://fpm.fortran-lang.org/en/spec/naming.html#custom-module-names) so perhaps our structure would be:

• http top-level module (public API)
• http_request
• http_response
• http_client

(and having the http as the prefix also allows the possibility of adding http_server in the future)

Another thing we should decide early is whether to use the old and inappropriate .f90 for source suffixes, or to just go with .f (now that free form is assumed, https://fpm.fortran-lang.org/en/spec/manifest.html#source-form). Since we just started, this project may be a perfect guinea pig to find out if there are any unforeseen issues with using .f for free-form sources.

So, my suggestion for this PR is to have these source files: http.f, http_client.f, http_request.f, and http_response.f.

Let me know what you all think.

[rajkumardongre]

Because the default __ thing is kinda ugly, we may want to use a custom prefix (https://fpm.fortran-lang.org/en/spec/naming.html#custom-module-names) so perhaps our structure would be:

• http top-level module (public API)
• http_request
• http_response
• http_client

Thank you, @milancurcic. I believe using a custom prefix would be a good approach, but I do have a concern. Our package name is http-client, which means that fpm will read it as http_client. According to fpm, the top-level module name must be the same as the package name. However, we are already using http_client as a module, which is not a top-level module. This could potentially confuse other developers about what our top-level module is: http or http_client To address this concern, can we rename our http_client module to something else, such as http_curl, http_server, or something else, while keeping http as our top-level module.

[milancurcic]

I see, good point. In that case, should we rename our package to just http? Shorter, simpler (no hyphen caveats), although less specific, but that's probably fine.

[rajkumardongre]

Yes, I also think http will be a good fit for our package name.

So now we can follow this structure :

• http top-level module (public API)
• http_request
• http_response
• http_client

[milancurcic]

OK, let's go ahead then and rename it in pyproject.toml and I'll rename the repo after we merge the PR.

[milancurcic]

It just occurred to me that this PR is also on a branch on fortran-lang/http-client rather than your fork (rajkumar/http-client). Please work only on development branches on your fork going forward. I'll merge this PR as is to not complicate further, and let's tackle the outstanding comments in separate PRs.