You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by rh...@apache.org on 2009/10/27 22:25:40 UTC
svn commit: r830345 - /qpid/trunk/qpid/python/todo.txt
Author: rhs
Date: Tue Oct 27 21:25:40 2009
New Revision: 830345
URL: http://svn.apache.org/viewvc?rev=830345&view=rev
Log:
added todo
Added:
qpid/trunk/qpid/python/todo.txt
Added: qpid/trunk/qpid/python/todo.txt
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/python/todo.txt?rev=830345&view=auto
==============================================================================
--- qpid/trunk/qpid/python/todo.txt (added)
+++ qpid/trunk/qpid/python/todo.txt Tue Oct 27 21:25:40 2009
@@ -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
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:commits-subscribe@qpid.apache.org