Thread: [asio-users] [ANN] emilua-beast 1.0
Brought to you by:
chris_kohlhoff
From: Vinícius d. S. O. <vin...@gm...> - 2024-08-30 21:45:32
|
Last year I announced emilua here as Lua bindings for Boost.ASIO. Starting at version 0.6 at the beginning of this year, I've removed all HTTP/WebSocket classes from the core package as I've felt they don't belong in the core. Today I'm announcing emilua-beast 1.0 which is something I've hacked together over this week: https://docs.emilua.org/beast/1.0/ref/beast.websocket.html Code is available at <https://gitlab.com/emilua/beast>. This new plugin only exposes WebSocket abstractions. However I've spent a good time re-reviewing it several times to make sure it's usable in production (code quality wise). Basically everything exposed under boost::beast::websocket::stream is present here... except for callbacks. Lua has true coroutines which means suspending anywhere. C++ callback-based interfaces don't work well for emilua. Therefore you won't find beast::websocket::stream_base::decorator to change/examine HTTP fields. I'll have to think of a callback-less interface to interact with HTTP fields within WebSocket context as some HTTP fields such as origin and sec-websocket-protocol are too important to ignore (you'll be unable to connect to many public endpoint if you don't set these fields). Feedback welcome. I'll be using this plugin to write a nostr client which parsers multimedia content in secure sandboxes so it should see some real-world usage hopefully. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Vinnie F. <vin...@gm...> - 2024-08-30 22:23:30
|
On Fri, Aug 30, 2024 at 2:46 PM Vinícius dos Santos Oliveira <vin...@gm...> wrote: ...you won't find beast::websocket::stream_base::decorator to change/examine HTTP fields. Would it help if Beast offered some new WebSocket APIs that create the Upgrade response and return it to you? And we could add extra websocket::stream APIs to perform the handshake assuming the caller has already sent the upgrade response? Thanks |
From: Vinícius d. S. O. <vin...@gm...> - 2024-08-30 23:30:03
|
Em sex., 30 de ago. de 2024 às 19:24, Vinnie Falco <vin...@gm...> escreveu: > Would it help if Beast offered some new WebSocket APIs that create the > Upgrade response and return it to you? And we could add extra > websocket::stream APIs to perform the handshake assuming the caller > has already sent the upgrade response? Back at emilua-0.5 when WebSocket+HTTP were part of the core package, that's how I've designed the interface for extra headers: <https://docs.emilua.org/api/0.5/ref/websocket.html#new-websocket>. However back in 0.5, I wasn't really worried about following Boost.Beast conventions. This new plugin mirrors Boost.Beast interfaces very closely and so far, only existing Boost.Beast methods are exposed. For the extra headers, I can follow the same design (add an extra parameter for handshake() in the Lua interfaces to represent the HTTP extra request headers... and inject them in the C++-side through the decorator interface). Would you consider that acceptable for Lua bindings for Beast? Having the author's approval would give me confidence in this design and I'd be able to solve the client case today. The server role is not as urgent and could enjoy some more time on design iterations. I don't think creating the upgrade response and returning it would be the way to go in emilua. Emilua needs an embedded HTTP server (never in core though). If one is inspecting HTTP headers, I feel the way to go would be to have an actual HTTP server. Beast already has two interfaces for separate HTTP server implementations: * Passing headers extracted from the HTTP layer: https://www.boost.org/doc/libs/1_86_0/libs/beast/doc/html/beast/ref/boost__beast__websocket__stream/accept/overload5.html * Generating HTTP response headers: https://www.boost.org/doc/libs/1_86_0/libs/beast/doc/html/beast/using_websocket/decorator.html Likewise, Boost.Beast already provides an embedded HTTP server. So maybe offer it as well in this plugin. If anyone writes it, I can approve the PR. I can also give admin powers in this repo to someone affiliated with Boost.Beast. However, on my own time, I don't see myself writing bindings for Beast's HTTP abstractions. I plan on spending time to write a curl plugin as lots of folks will only ever trust curl to handle HTTP streams. Thoughts? -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Vinícius d. S. O. <vin...@gm...> - 2024-08-31 11:32:58
|
Here's what I had in mind for the client role: https://gitlab.com/emilua/beast/-/commit/4c7059cea27a65fbf302fa9a866932563a09de2f In retrospect, my previous email wasn't very clear in this part. So I decided to just commit some code to show what I had in mind. Now you can use Lua code such as the following to insert extra headers in the client handshake: ws:handshake(host, '/ws/api/v2', { origin = host }) Boost.Beast C++ API is different. Would this choice be acceptable for Lua bindings even if it deviates from the C++ API? That's what I was trying to ask. If it's okay, I can tag a new release with this code and release a new ArchLinux package. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |
From: Vinnie F. <vin...@gm...> - 2024-08-31 19:37:27
|
On Sat, Aug 31, 2024 at 4:33 AM Vinícius dos Santos Oliveira <vin...@gm...> wrote: > Boost.Beast C++ API is different. Would this choice be acceptable for Lua bindings even if it deviates from the C++ API? In short, yes it is acceptable. Adding fields to a client handshake is a common operation, and there is no reason not to have this API. We could in theory add it to Beast, someone just needs to open an issue. However, your implementation is also OK. Thanks |
From: Vinícius d. S. O. <vin...@gm...> - 2024-08-31 22:07:12
|
Em sáb., 31 de ago. de 2024 às 16:38, Vinnie Falco <vin...@gm...> escreveu: > On Sat, Aug 31, 2024 at 4:33 AM Vinícius dos Santos Oliveira > <vin...@gm...> wrote: > > Would this choice be acceptable for Lua bindings even if it deviates from the C++ API? > > In short, yes it is acceptable. Okay, I've also added bindings to Beast errors and released a new version. URL to the docs changed to <https://docs.emilua.org/beast/1.1/ref/beast.html>. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ |