added todo

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@830345 13f79535-47bb-0310-9956-ffa450edef68

1 files changed, 215 insertions, 0 deletions

diff --git a/python/todo.txt b/python/todo.txt
new file mode 100644
index 0000000000..54c8f84484
--- /dev/null
+++ b/python/todo.txt
@@ -0,0 +1,215 @@
+Key:
+  F = Functional
+  PF = Partially Functional
+  NR = Needs Additional Review
+  ND = Needs Additional Design
+  NF = Not Functional
+
+Connection:
+
+  variables/configuration:
+
+    - reconnect: F, NR, ND
+      + reconnect functionality is done and the API semantics provided
+        are ready for review
+      + reconnect policies need to be finished, there is currently
+        only one hardcoded reconnect policy (retry every three
+        seconds), we need to define the pre-canned policies that we
+        want to support and a means to configure them, as well as a
+        very simple plugin/callback for defining ad-hoc policies
+      + need to feed failover exchange into the reconnect policy
+      + acks can be lost on reconnect
+      + handle reconnect during commit/rollback
+
+    - timeout: NF
+      + some sort of timeout threshold for killing the connection
+
+  methods:
+
+    - open/__init__: F, ND
+      + need to support kerberos
+      + need a better way of supplying various kinds of configuration:
+        - authentication info
+        - transport specific configuration options, e.g
+          - heartbeat
+          - socket options
+            - tcp-nodelay
+        - multiple brokers
+
+    - session: F, NR
+
+    - connect: F, NR
+
+    - disconnect: F, NR
+
+    - connected: F, NR
+
+    - start: F, NR, ND
+      + see comment on Receiver.start
+
+    - stop: F, NR, ND
+      + see comment on Receiver.start
+
+    - close: F, NR, ND
+      + currently there is no distinction between a "close" that does
+        a complete handshake with the remote broker, and a "close"
+        that reclaims resources, this means that close can fail with
+        an exception, I don't like this as it is unclear to the user
+        if there is a responsibility to do further cleanup in this
+        case
+
+  errors:
+
+    - ConnectionError: F, NR
+      + ConnectError F, NR
+      + Disconnected F, NR
+
+    - notification of disconnect?
+
+Session:
+
+  methods:
+
+    - sender: F, NR, ND
+      + need to detail address options
+      + need to define subject pattern semantics
+      + consider providing convenience for sender/receiver caching
+
+    - receiver: F, NR, ND
+      + need to detail address options
+      + need to define filter syntax/semantics
+      + consider providing convenience for sender/receiver caching
+
+    - acknowledge: F, NR
+
+    - reject: NF
+
+    - release: NF
+
+    - commit: F, NR
+
+    - rollback: F, NR
+
+    - start: F, NR, ND
+      + see comment on Receiver.start
+
+    - stop: F, NR, ND
+      + see comment on Receiver.start
+
+    - fetch: NF
+      + this method if added would permit the listener functionality
+        to be removed as it would become trivial to replicate via user
+        code
+
+    - close: F, ND
+      + see comment on Connection.close
+
+  errors:
+
+    - SessionError: F, NR, ND
+      + SendError: F, NR, ND
+      + ReceiveError: F, NR, ND
+      + should there be fatal/non fatal variants?
+
+Sender:
+
+  methods:
+
+    - pending: F, NR
+
+    - send: F, NR
+
+    - sync: F, NR, ND
+      + currently this blocks until pending == 0, I'm thinking of
+        renaming this to wait and adding a slightly richer interface
+        that would let you wait for something like pending < n
+
+    - close: F, NR
+
+  errors:
+
+    - SendError
+      + InsufficientCapacity
+      + need specific subhierarchy for certain conditions, e.g. no such queue
+
+Receiver:
+
+  methods:
+
+    - pending: F, NR
+
+    - listen: F, ND
+      + see comment on Session.fetch
+
+    - fetch: F, NR, ND
+      + explicit grant for receiver
+      + changing capacity/prefetch to issue credit on ack rather than
+        fetch return
+
+    - start: F, NR, ND
+      + when a receiver is "stopped", it is treated as if the receiver
+        has zero capacity even if the capacity field is set to a non
+        zero value, this is a mild convenience since you can stop and
+        then start a receiver without having to remember what the
+        capacity was before, however it is unclear if this is really
+        worthwhile since stop/start is entirely equivalent to setting
+        capacity to a zero/non-zero value
+
+    - stop: F, NR, ND
+      + see comment on Receiver.start
+
+    - sync/wait: NF
+
+    - close: F, NR
+
+  errors:
+
+    - ReceiveError
+      + Empty
+      + need specific subhierarchy for certain conditions, e.g. no such queue
+
+Message:
+
+  - standard message properties: F, NR, ND
+
+  - map messages: F, NR
+    + needs interop testing: NF
+    + needs java impl: NF
+
+  - list messages: F, NR, NI
+    + needs interop testing: NF
+    + needs java impl: NF
+
+  - boxed types: NF
+
+Address:
+
+  - syntax: F, NR
+  - subject related changes, e.g. allowing patterns on both ends: NF, ND
+  - creating/deleting queues/exchanges
+    + need to handle cleanup of temp queues/topics: NF
+    + passthrough options for creating exchanges/queues: NF
+  - integration with java: NF
+  - queue browsing: NF
+  - temporary queues: NF
+  - xquery: NF
+
+Testing:
+  - stress/soak testing for async: NF
+  - stress/soak testing for reconnect: NF
+  - interop testing: NF
+  - multi session and multi connection client tests: NF
+
+Documentation:
+  - api level docs largely present but need updating and elaboration
+  - tutorial: NF
+
+Examples:
+  - drain: F, NR
+  - spout: F, NR
+  - server: F, NR
+  - client: NF
+  - other examples, e.g. async?
+
+Miscellaneous:
+  - standard ping-like (drain/spout) utilities for all clients: NF