2003-10-14 Havoc Pennington <hp@redhat.com>
[platform/upstream/dbus.git] / doc / TODO
index 843d4e1..6257b09 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,7 +1,4 @@
-
- - Message matching rules (so broadcasts can be filtered) need sorting
-   out.
-
  - How we will handle DCOP needs sorting out. Among other things, we
    need to check that service and service-ownership semantics map to DCOP 
    reasonably well.
@@ -34,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.
@@ -45,8 +39,6 @@
    after the message bus has processed your message but before the service has replied, 
    it would be nice if the message bus sent you an error reply.
 
- - write a DTD for the dbus-daemon-1 configuration file
-
  - build and install the Doxygen manual in Makefile when --enable-docs
 
  - if you send the same message to multiple connections, the serial number 
    files; they have to be in the toplevel file. when loading 
    a child file, we could just init its DBusLimits from the parent, 
    then after parsing copy its DBusLimits back to the parent
+
+ - when making a method call, if the call serial were globally unique,
+   we could forward the call serial along with any method calls made
+   as a result of the first method call, and allow reentrancy that was
+   strictly part of the call stack of said method call. But I don't
+   really see how to do this without making the user pass around the
+   call serial to all method calls all the time, or disallowing 
+   async calls.
+
+ - the invalid messages in the test suite are all useless because 
+   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" 
+   perhaps.
+
+ - modify the auth protocol to also support other initial-handshake
+   type of information
+
+ - document the auth protocol as a set of states and transitions, and
+   then reimplement it in those terms
+
+ - dbus_gproxy or dbus_g_proxy?
+
+ - add dbus_message_has_path(), maybe has_member/interface
+
+ - The OBJECT_PATH type is not documented in the spec.
+
+ - re_align_field_recurse() in dbus-message.c is broken because it 
+   crashes on some types of header field values. security problem.
+
+ - the system daemon has to be able to reload changes to the 
+   security policy without restarting, because apps won't 
+   be coded to handle it restarting
+
+ - modify the wire protocol to keep the args signature separate 
+   from the args themselves. Make the name of TYPE_NAMED part 
+   of the type signature, rather than part of the value.
+   Then you have the full typecheck in a single string.
+
+ - rename TYPE_NAMED to TYPE_CUSTOM, probably a clearer name.
+
+ - dbus_message_iter_init_array_iterator has "iter" and "iterator" 
+   in the same function name
+
+ - 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