new internall http interface?

[RodrigoDornelles]

The current HTTP API was made using Wasmoon, which has perfect interpolation with JavaScript, which meant that the structure did not need to be so thought out. However, there is a difficulty in supporting HTTP on native platforms precisely because of this, but changing this interface implies other HTTP supports such as Love2D and especially Ginga.

a hybrid interface between the old and new? gradually migrating to the new one?

small idea of ​​what the interface for core native could be like.

native_http_handler(request_id)             -- exist, Lua calling C
native_http_get_table(request_id)           -- anti-pattern function: C calling lua
native_http_set_status(request_id, value)   -- anti-pattern function: C calling lua
native_http_set_error(request_id, value)    -- anti-pattern function: C calling lua
native_http_set_data(request_id, value)     -- anti-pattern function: C calling lua
native_http_promise(request_id)             -- anti-pattern function: C calling lua
native_http_resolve(request_id)             -- anti-pattern function: C calling lua

allow both interfaces at the same time?
create a handler for wasmon and another for fengari in HTML5?

[RodrigoDornelles]

perhaps another idea, which is more standard with the engine structure, is to create a native_callback_http similar to the ginga ncl event, however, with the possibility of returns and creating events like get_url get_method and set_data... it would be interesting.

native_http_handler(dict, request_id) 
native_callback_http(evt, request_id, data)

can co-exist with wasmon and fengari, and is not antipattern, but it takes the work of implementing a redundant protocol with the std.http frontend API

• async_promise
• async_resolve
• get_url
• get_method
• get_body_data
• get_param_count
• get_param_data
• get_header_count
• get_header_data
• set_status
• set_error
• set_body_data