Closed dvv closed 11 years ago
the first two are addressed in https://github.com/dvv/moonslice-luv/commit/97fe8dae81d4df8d150e382f8c6ab232dbdaefd7
forth is addressed by https://github.com/dvv/moonslice-luv/commit/d5f9aaf95b8581cfbfc6acd847b1e35aeb7d1c74 -- i hesitate to make changes to luv_write
to make it accept tables as chunk until it's said feasible
Caching the Server
header value is fine. Caching the Date header smells like premature optimization. How expensive is it? What's the affect it has on performance.
On chunked encoding, I may have read the spec wrong, but this is how I read it and it works with curl as a client. If my implementation is wrong, I'm fine with changing it to be correct.
I think body as a table is a great idea. We'll have to see if it's faster to accept the table at the luv binding layer and have one uv_write call or handle the table at the stream layer and convert it to multiple writes. I'm hoping it's faster to have one uv_write call.
We could measure Date evaluation but I believe it is rather expensive as all that deals with complex stringification, even being done in C.
Passing multiple buffers to to uv_write
showed significant speedup when I measured it in my early luv development. String concats are so slow in Lua.
Just FYU, noticed that presenting a readstream with a table with read key can be reduced to just read function per se, when analyzing what an app handler returns as response body. This would save us to treat returned table as pure io_list and simplify response logic.
IMHO
What do you think?