dbus/doc TODO,1.27,1.28

[Havoc Pennington]

Update of /cvs/dbus/dbus/doc
In directory pdx:/tmp/cvs-serv2308/doc

Modified Files:
	TODO 
Log Message:
2003-10-14  Havoc Pennington  <hp@redhat.com>

	* bus/connection.c: implement pending reply tracking using
	BusExpireList

	* bus/bus.c (bus_context_check_security_policy): verify that a
	reply is pending in order to allow a reply to be sent. Deny 
	messages of unknown type.

	* bus/dbus-daemon-1.1.in: update to mention new resource limits

	* bus/bus.c (bus_context_get_max_replies_per_connection): new
	(bus_context_get_reply_timeout): new



Index: TODO
===================================================================
RCS file: /cvs/dbus/dbus/doc/TODO,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -d -r1.27 -r1.28
--- TODO	12 Oct 2003 05:59:39 -0000	1.27
+++ TODO	14 Oct 2003 05:16:56 -0000	1.28
@@ -31,9 +31,6 @@
    some basic spec'ing out of the GLib/Qt level stubs/skels stuff will be 
    needed to understand the right approach.
 
- - there are various bits of code to manage ref/unref of data slots, that should 
-   be merged into a generic facility
-
  - assorted _-prefixed symbols in libdbus aren't actually used by
    libdbus, only by the message bus. These bloat up the library
    size. Not sure how to fix, really.
@@ -73,7 +70,10 @@
    async calls.
 
  - the invalid messages in the test suite are all useless because 
-   they are invalid for the wrong reasons due to protocol changes
+   they are invalid for the wrong reasons due to protocol changes.
+   (Consider extending test suite to validate that they are 
+   invalid for right reason, e.g. an "INVALID_ERROR Foo" line 
+   in the message files)
 
  - I don't want to introduce DBusObject, but refcounting and object
    data could still be factored out into an internal "base class" 
@@ -111,3 +111,10 @@
  - the GLib bindings varargs take DBUS_TYPE_WHATEVER and 
    return stuff allocated with dbus_malloc(); should this 
    be made more "G" at some expense in code duplication?
+
+ - need to define bus behavior if you send a message to 
+   yourself; is it an error, or allowed? If allowed, 
+   we need to have a test for it in the test suite.
+
+ - the max_replies_per_connection resource limit isn't implemented
+