diff options
author | Havoc Pennington <hp@redhat.com> | 2003-10-14 05:16:56 +0000 |
---|---|---|
committer | Havoc Pennington <hp@redhat.com> | 2003-10-14 05:16:56 +0000 |
commit | 64f5ae1a79a8cd86a3aae55e485729da438d84d0 (patch) | |
tree | ab2bc587211d813d8bb224db51c1f6446d05aa2c /doc | |
parent | bfb5de511cbc072aca59189efc1324397d8993fd (diff) |
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
Diffstat (limited to 'doc')
-rw-r--r-- | doc/TODO | 15 |
1 files changed, 11 insertions, 4 deletions
@@ -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 + |