evo-lua / evo-legacy

[Obsoleted Prototype] Highly experimental Lua runtime environment built on Luvi (libuv + LuaJIT)
https://evo-lua.github.io
0 stars 0 forks source link

Evaluate the available options for adding a high-level networking library to the environment #28

Open rdw-software opened 2 years ago

rdw-software commented 2 years ago

Built on libuv. Can probably use luvit and mode's net as a starting point to come up with a better design (see coro-net?)

Functionality:

Probably split into multiple issues (and extensions) due to the complexities involved.

rdw-software commented 2 years ago

I did some prototyping and see no issues why Luvit's coroutine-based libraries couldn't be used. It's not the BEST solution since they won't be competitive with NodeJS's current ones (Luvit is basically the NodeJS APIs from many years ago, cruft and all), as porting all of that over would not only take an incredible amount of time, but also require adopting a lot of their design:

The security concerns are not alleviated by using Luvit's APIs, as they can hardly be considered secure due to lack of peer review and widespread usage. I guess there's no proper solution for it, so the best approach seems to be a) using established C libraries, which complicates the build process and adds a lot of headaches, or b) just get something working and refine/review security over time.

Just for fun I tried to simply build the libwebsockets library as it claims to integrate with libuv, but it's pretty much what you'd expect from a C library and its "oldschool" style of documentation... so no thanks, I guess. Not really worth the hassle right now; perhaps later it can be revisited. Crypto is less of a problem since openssl is already integrated with the runtime, though of course using it right is ever a challenge.

I still want to port as many of the test cases, at least those that seem relevant/indepent of their low-level implementation. There's a metric ton of those so it would likely still take too much time, but we'll see.

Also, the API design I'm not a fan of, so perhaps that could be re-evaluated. There's a few standards that need to be considered:

  1. Luvit/NodeJS style: Reads like JavaScript, not really great for a Lua environment
  2. Low-level/classic Lua style: More fitting, and already adopted for the builtins and primitives in Luvi. The high-level APIs don't lend themselves as well to it and should probably also be logically separated from the low-level stuff
  3. WOW API style (C_Namespaces). I personally like this a lot, and it mixes well with standard Lua notation for low-level stuff, but it might appear somewhat inconsistent

Currently favouring option 3. Will likely use that to prototype and then see how it turns out - the API style can always be adjusted later.

rdw-software commented 2 years ago

Update on lws: I was able to build it now, it was just a misconfigured path/poor documentation issue. Either way, that seems like a better solution to the security concerns, and it does include facilities for http/http2/https and even DNS (not sure if ALL of Node's functionality is covered). Definitely worth exploring more, so I'll create a separate issue for possibly integrating it with the runtime. It's a bit silly to have two libraries for networking, since libuv already features tcp, udp, dns but higher-level protocols would still be useful.