Re: Xcb luajit bindings exist?
- From: Daurnimator <quae@xxxxxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 23 Aug 2015 23:59:26 +1000
On 23 August 2015 at 23:23, Cosmin Apreutesei
<cosmin.apreutesei@xxxxxxxxx> wrote:
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)
Maybe I'm missing something obvious but what does any of that have to
do with the http protocol?
- HTTP2 has multiple streams over the one connection: you need some
kind of multiplexing here; and a coroutine scheduler is the best way
in lua.
- HTTP2 has all sorts of TLS requirements. see e.g.
https://http2.github.io/http2-spec/#TLSUsage
- For compatibility with bad http 1.0 servers you need to make sure
there is a TCP packet boundary after the headers
- You need shutdown(SHUT_WR) to indicate the end of a body in HTTP 1.1
- Coming soon: For fast connection establishment you need to send
data in the connect() (TCP fast open)
I see cqueues as a particular good solution, as it doesn't tie you
into a particular event library.
I thought cqueues is Unix-only (it says so on the homepage).
It is Unix only for now; one day I hope it can be ported to windows.
Portability between event loops/application architectures is very
different to portability between operating systems.
Of course, there is plenty of places that are neither Unix nor
Windows: for these I don't have a great answer.
For bare metal boards without operating systems, I suppose they'd have
to provide an alternate low level connection layer for lua-http.
For high level environments (e.g. compiling to JS for the browser),
you would have to write compatibility layers across to whatever the
browser DOM supports.
Both of these are bound to end up not providing certain bits of
functionality e.g.
- not enough space for a TLS library
- no taking over raw socket ownership e.g.for a connection: upgrade
(browsers don't have such a thing)
- no arbitrary requests (cause of CORS and such)
Other related posts:
