To Summarize:
It seems we agree that:
* The event loop must be usable in a headless environment.
* The net lib looks after buffering
* The net lib looks after reconnection attempts
* Low Level Network events can be posted to the event loop.
- Incoming low level network events is good for people who hack
their own protocols
- Perhaps the low level events are blocked by default?
* USEREVENTs can be posted to the event loop
- the events come from from incoming network data
But we don't yet agree on, or haven't considered:
* Does the select call run in a different thread?
- This is allows apps which use pygame.event.wait to work correctly.
- However, most games do not use pygame.event.wait
* Can the net lib can be used without the event loop?
For the record, I have implemented an event dispatch mechanism which
works over a TCP connection. I post pygame events into the same
dispatch mechanism, and use it for my main game loops. It works very
well. Unfortunately, it depends on twisted, doesn't provide UDP, and
requires an explicit poll call. It does however, show that this style
of networking can work in real applications. Howeverm one thing I have
found that I do need at times is some form of request / response
construct, which simple event passing doesn't automatically provide.
It has a safe serializer, which is something this SoC proposal will
need to implement if USEREVENT's are going to be passed across a
network, and reconstructed into usable events.
Network Event Dispatch:
http://trac.xerian.net/trac/xerian.net/browser/FibraNet/trunk/eventnet
Safe Serializer:
http://trac.xerian.net/trac/xerian.net/browser/FibraNet/trunk/gherkin.py
-Sw.