todo update

diff --git a/doc/todo.txt b/doc/todo.txt
index c4e1e9f2e0f54e78d47f49fc2512d1a8bcfb4f55..ba89d9476353396f65b4839358e56663fc6ec051 100644 (file)
--- a/doc/todo.txt
+++ b/doc/todo.txt
@@ -1,24 +1,36 @@
 = PgBouncer TODO list =
 
-== Slightly urgent features ==
+== Highly visible missing features ==
+
+Significant amount of users feel the need for those.
 
  * auth_conn - access to pg_shadow, so auth_file is not needed.
-   [ flat-text files are gone in 8.5+ ]
+   [ flat-text files are gone in 9.0+ ]
+
+ * Protocol-level plan cache.
+
+ * LISTEN/NOTIFY.  Requires strict SQL format.
+
+ * SSL support.  Although stunnel works for plain SSL,
+   it cannot be linked with Postgres authentication.
+
+ * Load-balancing / failover.
+
+Waiting for contributors...
+
+== Problems / cleanups ==
+
+ * Maintenance order vs. lifetime_kill_gap:
+   http://lists.pgfoundry.org/pipermail/pgbouncer-general/2011-February/000679.html[]
+
  * per_loop_maint/per_loop_activate take too much time in case
    of moderate load and lots of pools.  Perhaps active_pool_list
    would help, which contains only pools touched in current loop.
+
  * new states for clients: idle and in-query.  That allows to apply
    client_idle_timeout and query_timeout without walking all clients
    on maintenance time.
 
-== Good-to-have features in transaction pooling ==
-
- * Protocol-level plan cache.
- * LISTEN/NOTIFY.  Requires strict SQL format.
-
-== Minor features ==
-
- * set server_reset_query = '';
  * check if SQL error codes are correct
  * removing user should work - kill connections
  * keep stats about error counts
@@ -32,42 +44,20 @@
    Needs a new sbuf_prepare_*() to notify sbuf about short data.
    [Plain 'false' from handler postpones processing to next event loop.]
 
-== Win32 features ==
-
- * Automatic registration of pgbevent.dll.  (Re-register also
-   if old DLL does not exist.)
- * PAUSE/RESUME via service control panel.
- * Online reboot by DuplicateHandle().  Main question is:
-   What should the UI look like?  Making it work for console
-   app seems easy, but it does not make sense at all without
-   working also for services.
-
 == Dubious/complicated features ==
 
+ * User-based route.  Simplest would be to move db info to pool
+   and fill username into dns.
  * units for config parameters.
  * some preliminary notification that fd limit is full
 
  * Move all "look-at-full-packet" situtations to SBUF_EV_PKT_CALLBACK
 
- * pid mapping for NOTIFY.
-
  * `pool_mode = plproxy` - use postgres in full-duplex mode for autocommit
    queries, multiplexing several queries into one connection.  Should result
    in more effiicent CPU usage of server.
 
-=== prepared plans ===
-
- * keeping track of protocol-level prepared plans
-
-=== load-balancing ===
-
- * allow serveral server to serve one db
-   - possibility to specify failover databases.
- * seems pointless - result would be less featureful HAProxy
-
-=== SMP awareness ===
-
- * spread sockets over per-cpu threads.  needs confirmation that
+ * SMP: spread sockets over per-cpu threads.  needs confirmation that
    single-threadedness can be problem.  it can also be that only
    accept() + login handling of short connection is problem.
    that could be solved by just having threads for login handling,