X-Git-Url: http://www.privoxy.org/gitweb/?p=privoxy.git;a=blobdiff_plain;f=TODO;h=b23841bcf237291e243b7ef3a368cb1161ca86ef;hp=7f07a10889653d283938aa32dd1b4559fcce3d41;hb=1e3471c05f279e9f4ebead3a943512d8919a70f3;hpb=a6bd59c5026c31d5621613f0665fb1827b0f02de diff --git a/TODO b/TODO index 7f07a108..b23841bc 100644 --- a/TODO +++ b/TODO @@ -1,4 +1,4 @@ -$Id: TODO,v 1.156 2017/01/23 13:06:53 fabiankeil Exp $ +$Id: TODO,v 1.165 2017/05/29 10:40:28 fabiankeil Exp $ Some Privoxy-related tasks, sorted by the time they have been added, not by priority. @@ -414,7 +414,7 @@ http://www.privoxy.org/faq/general.html#DONATE forward-override). Investigate and fix or document. 141) Port Privoxy to CloudABI, which, despite the name, is actually - rather neet. https://github.com/NuxiNL/cloudlibc + rather neat. https://github.com/NuxiNL/cloudlibc 142) Remove or update the "internal" pcre version. @@ -439,9 +439,6 @@ http://www.privoxy.org/faq/general.html#DONATE currently can result in client requests to config.privoxy.org on the Internet which may not be desirable. -149) Use poll() for socket selection so the number of sockets Privoxy - can deal with isn't limited to FD_SETSIZE anymore. - 150) Add blacklistd support. 151) Let the dok-tidy target work cross-platform without introducing @@ -453,6 +450,30 @@ http://www.privoxy.org/faq/general.html#DONATE duplicated requests are pointless even if they don't end up with a 404. +153) Catch SIGINT and use it to close the listen socket, serve + remaining connections and shut down. This would allow higher + uptime and make testing more convenient. + +154) Underline links in docs and cgi pages. More precisely, + don't mess with the browser defaults for link underlining. + +155) The sig_handler() shouldn't call log_error(). + While it isn't known to cause actual problems in normal operation, + it's technically incorrect and causes crashes when running in + valgrind. + +156) Reject socks requests with an explicit error message similar + to the one used for ftp. Motivation: + https://lists.privoxy.org/pipermail/privoxy-users/2017-March/000195.html + +158) Use a single thread to wait for new requests on reused client connections. + Currently the thread that handles the first request on a connection + stays responsible for the client connect until it gets closed. + In case of lots of idle connections lots of waiting threads are used. + While it's conceivable that this ineffiency is irrelevant from a + performance point of view, using a single thread should reduce Privoxy's + memory footprint a bit which may be noticeable in case of multi-user setups + with hundreds of idle connections. ########################################################################## Hosting wish list (relevant for #53)