index.cgi/trunk/TODO

For 0.7.1:
o) Fix any bugs with XCodec EOS support.
o) Add an ActionCache which classes can use to dole out Actions and which at
   destruction time will assert that there are no outstanding actions.  This
   will make debugging code involving Actions easier and give better Action
   allocation performance, done properly.
o) Rewrite PipeLink to constantly poll for spontaneous output.  Make sure all
   other things can handle spontaneous output.
o) Make XCodecEncoder and XCodecDecoder pipes outright so as to avoid all of
   the weird interactions between each and its Pipe variant.

For 0.7.2:
o) A better look-ahead parser.
o) Test error handling in epoll.
o) Test error handling with port(3C).
o) Condition variables to suppport spontaneous output from XCodecEncoderPipe.
o) Make UnixClient and UnixServer take the SocketType as an argument to make
   it possible to support both stream-orientation and datagram-orientation?
   Would need to update UnixServer's API to support both models.
o) Something higher-level than Pipe which supports various disciplines and
   makes it easier to write stream processing modules.
o) Make *Client::connect() work like TCPClient::connect().
o) Move to the getrusage-based Timer class and make it clear that that is what
   it is for.  Perhaps create a Timer base class and a UserTimer and WallTimer
   for real use?
o) Add a flush token for Pipe::input() ?
o) Add a flesh Event type for Pipe::output() ?
   XXX It's unclear, but I think a flush method or similar may be needed to
       implement buffer limiting?  A flush method being like input(), except
       that it only returns once the last Pipe in the Pipeline has returned
       flush complete, or error if data cannot be flushed because there is not
       enough to finish processing the data that is pending, at which point
       you at least know that everything else has been flushed?
o) Make Pipe::input take a parameter to send EOS along with data.
o) How do we find out if remote has shut down read channel so we can stop
   writing and shut down a Splice?
o) Make interface/listener objects automatically start listening.
o) Clean up address configuration objects to be more sensible, being either
   specific components of addresses (e.g. to specify an IP address) or socket
   addresses (e.g. AF_UNIX paths, IP+port pairs for TCP or UDP or SCTP.)
o) Connector abstraction: connection pooling / connecting via a SOCKS server.

For 0.8.0:
o) Cache hierarchy, including persistent storage.
o) TLS.

For 0.9.0:
o) Handle OOB data.

After 1.0.0:
o) A CLI program for management.  Remember to USE_POLL=select since Mac OS X can
   only use select(2) for stdin and stdout.
o) Make it possible to detect when we are sending to a socket that is also
   within WANProxy and avoid a system call -- just copy directly to the
   appropriate buffer.  It should be pretty easy to do this with the IO queueing
   system if we getpeername/getsockname to identify this occurring.
o) Add an IO queueing system that will make it possible to use lio_listio on
   systems that support it.
o) Make the XCodec encoder and decoder asynchronous.
o) Connection table. Database.
o) HTTP termination and reinitiation good enough to support an HTTP proxy mode.

Ongoing:
o) Add lots of comments.
o) Fix bugs.
o) Audit log levels.
o) Try to remove HALTs and NOTREACHEDs that aren't legitimate.
o) Give better debug information from configuration system.

Maybe:
o) A resolver that's less fragile than the OS-supplied ones.  Mac OS X, at
   minimum, neither keeps a pool of file descriptors nor errors out gracefully
   when the OS is out of them, leading to hangs.
o) Send definitions out-of-band, too, so that QoS and backpressure on one
   connection can't delay other connections.
o) In-path forwarding using BPF and a tiny network stack.
o) Run-length-encoding.
o) Many compression algorithms.
o) Allow chaining codecs.
o) SOCKS IPv6 support.
o) Some decent way to configure Pipelines.
o) Figure out a good name for a Pipeline, since Pipeline seems rubbish.
o) Merge two Pipelines.
o) Convert the SOCKS proxy server to a PipeEndpoint that merges the Pipeline
   that it is connected to with a newly-created one.
o) Be less protocol-ignorant; add protocol-aware framing to WANProxy.  For
   example, HTTP response headers are likely to include some amount of changing
   data (timestamps, etc.) so perhaps it's better to take a clean shot at the
   start of the content.  And perhaps it's better to convert to large chunks in
   chunked encoding mode to get bigger windows of data to encode.  No need to
   remember the last 3 bytes of a chunk, the chunk header, and the next N bytes,
   if the chunks won't be laid out the same every time.  Right?
1	For 0.7.1:
2	o) Fix any bugs with XCodec EOS support.
3	o) Add an ActionCache which classes can use to dole out Actions and which at
4	destruction time will assert that there are no outstanding actions. This
5	will make debugging code involving Actions easier and give better Action
6	allocation performance, done properly.
7	o) Rewrite PipeLink to constantly poll for spontaneous output. Make sure all
8	other things can handle spontaneous output.
9	o) Make XCodecEncoder and XCodecDecoder pipes outright so as to avoid all of
10	the weird interactions between each and its Pipe variant.
11
12	For 0.7.2:
13	o) A better look-ahead parser.
14	o) Test error handling in epoll.
15	o) Test error handling with port(3C).
16	o) Condition variables to suppport spontaneous output from XCodecEncoderPipe.
17	o) Make UnixClient and UnixServer take the SocketType as an argument to make
18	it possible to support both stream-orientation and datagram-orientation?
19	Would need to update UnixServer's API to support both models.
20	o) Something higher-level than Pipe which supports various disciplines and
21	makes it easier to write stream processing modules.
22	o) Make *Client::connect() work like TCPClient::connect().
23	o) Move to the getrusage-based Timer class and make it clear that that is what
24	it is for. Perhaps create a Timer base class and a UserTimer and WallTimer
25	for real use?
26	o) Add a flush token for Pipe::input() ?
27	o) Add a flesh Event type for Pipe::output() ?
28	XXX It's unclear, but I think a flush method or similar may be needed to
29	implement buffer limiting? A flush method being like input(), except
30	that it only returns once the last Pipe in the Pipeline has returned
31	flush complete, or error if data cannot be flushed because there is not
32	enough to finish processing the data that is pending, at which point
33	you at least know that everything else has been flushed?
34	o) Make Pipe::input take a parameter to send EOS along with data.
35	o) How do we find out if remote has shut down read channel so we can stop
36	writing and shut down a Splice?
37	o) Make interface/listener objects automatically start listening.
38	o) Clean up address configuration objects to be more sensible, being either
39	specific components of addresses (e.g. to specify an IP address) or socket
40	addresses (e.g. AF_UNIX paths, IP+port pairs for TCP or UDP or SCTP.)
41	o) Connector abstraction: connection pooling / connecting via a SOCKS server.
42
43	For 0.8.0:
44	o) Cache hierarchy, including persistent storage.
45	o) TLS.
46
47	For 0.9.0:
48	o) Handle OOB data.
49
50	After 1.0.0:
51	o) A CLI program for management. Remember to USE_POLL=select since Mac OS X can
52	only use select(2) for stdin and stdout.
53	o) Make it possible to detect when we are sending to a socket that is also
54	within WANProxy and avoid a system call -- just copy directly to the
55	appropriate buffer. It should be pretty easy to do this with the IO queueing
56	system if we getpeername/getsockname to identify this occurring.
57	o) Add an IO queueing system that will make it possible to use lio_listio on
58	systems that support it.
59	o) Make the XCodec encoder and decoder asynchronous.
60	o) Connection table. Database.
61	o) HTTP termination and reinitiation good enough to support an HTTP proxy mode.
62
63	Ongoing:
64	o) Add lots of comments.
65	o) Fix bugs.
66	o) Audit log levels.
67	o) Try to remove HALTs and NOTREACHEDs that aren't legitimate.
68	o) Give better debug information from configuration system.
69
70	Maybe:
71	o) A resolver that's less fragile than the OS-supplied ones. Mac OS X, at
72	minimum, neither keeps a pool of file descriptors nor errors out gracefully
73	when the OS is out of them, leading to hangs.
74	o) Send definitions out-of-band, too, so that QoS and backpressure on one
75	connection can't delay other connections.
76	o) In-path forwarding using BPF and a tiny network stack.
77	o) Run-length-encoding.
78	o) Many compression algorithms.
79	o) Allow chaining codecs.
80	o) SOCKS IPv6 support.
81	o) Some decent way to configure Pipelines.
82	o) Figure out a good name for a Pipeline, since Pipeline seems rubbish.
83	o) Merge two Pipelines.
84	o) Convert the SOCKS proxy server to a PipeEndpoint that merges the Pipeline
85	that it is connected to with a newly-created one.
86	o) Be less protocol-ignorant; add protocol-aware framing to WANProxy. For
87	example, HTTP response headers are likely to include some amount of changing
88	data (timestamps, etc.) so perhaps it's better to take a clean shot at the
89	start of the content. And perhaps it's better to convert to large chunks in
90	chunked encoding mode to get bigger windows of data to encode. No need to
91	remember the last 3 bytes of a chunk, the chunk header, and the next N bytes,
92	if the chunks won't be laid out the same every time. Right?