The LowLevelServer is a direct interface to the parser given people access
to things like partially received headers. This could be used to implement
an extremely optimized server which acts before parsing is complete.
Most people will be using node.http.Server which is still rather low-level
compared to other http interfaces, but does take care of some details for
you.
Connections were being garbage collected while they were still in progress
since the object would leave scope. This commit adds ObjectWrap::Attach()
and ObjectWrap::Detach() to tell v8 that an object is currently on the event
loop and will be needed in the future.
Other changes to oi_socket.c and net.cc are to fix bugs encountered while
running the HTTP server.
For server-side sockets, no longer pass the server object to the
js constructor. This is set later with SetAcceptor.
I think the change is a bit strage and convoluted but it allows one give
protocol /classes/ to the c++ constructors instead of protocol instances.
This is nice because derived classes (like HTTP) don't need to copy the
protocol instanciation code.
Here I massively change both the external and internal API of the TCP
sockets and servers.
This change introduces the concept of a protocol object like is found in
Twisted Python. I believe this allows for a much cleaner description of how
a socket behaves. What was once a single object "client" or "connection" is
now represented by two objects: a "connection" and a "protocol".
Well - I don't want to ramble too much because neither API is yet public or
documented. Look the diff of test/test-pingpong.js to see how things have
changed.
Also changed Init_net() to Socket::Initialize() and Server::Initialize().
Seems more object oriented, but I'm unsure how this will play when I want
load modules dynamically with dlopen(). I'll sit with it for a while and
see how it feels.
This might need to be changed in the future if ev is needed in thread pools
or extension libraries. However for now it makes sense to just use a single
loop.
Ryan