Re: Xcb luajit bindings exist?
- From: Daurnimator <quae@xxxxxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 23 Aug 2015 23:01:21 +1000
On 23 August 2015 at 22:14, Cosmin Apreutesei
<cosmin.apreutesei@xxxxxxxxx> wrote:
- Due to using cqueues:
Am I alone in thinking that HTTP (or any protocol) should be a pure
Lua library with no dependencies that should work over user-provided
read() and write() functions (plus utilities like compress(),
decompress(), md5() etc) ? Why is everybody bundling I/O, thread
abstractions, buffering schemes and protocols together? Wouldn't say,
lua-resty-mysql have a greater chance at attracting dev power (and
thus a greater chance at completeness and robustness) if it would not
be tied to openresty's I/O? Same goes for luasocket's http module or
many others (not picking on any one in particular).
Raise your hand if you're sharing my aversion to frameworks and
kitchen-sink libraries :)
The issue is that for a good library, you need much more than just
reading and writing from a socket.
e.g. inside of lua-http, I've also needed:
- socket buffering (including flushing and :unget; which needs to be
able to be optionally fed back to through TLS)
- a coroutine scheduler
- that supports locking
- a TLS library
- that supports mid-stream TLS upgrades
- that supports ALPN
- slightly advanced tcp flags such as NOPUSH
- shutdown(2)
I see cqueues as a particular good solution, as it doesn't tie you
into a particular event library.
==> it will happily play with libevent, libev, libuv, and select.
This means people will be able to use lua-http without signing up for
the rest of cqueues.
Other related posts:
