2004-06-07 Havoc Pennington <hp@redhat.com>

	* doc/TODO: remove auto-activation item since it's done; sort
	items by importance/milestone

1 files changed, 87 insertions, 70 deletions

diff --git a/doc/TODO b/doc/TODO
index a35a6a41..d89620bb 100644
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,5 +1,5 @@
- - Probably no point in a version number in the daemon name
-   (s/dbus-daemon-1/dbus-daemon/)
+Important for 1.0
+===
   
  - How we will handle DCOP needs sorting out. Among other things, we
    need to check that service and service-ownership semantics map to DCOP 
@@ -7,27 +7,100 @@
 
  - Activation needs some careful additional thinking-through.
 
+ - Audit @todo and FIXME for security issues
+
+ - The convenience functions in dbus-bus.h should perhaps have
+   the signatures that they would have if they were autogenerated
+   stubs. e.g. the acquire service function. We should also evaluate 
+   which of these functions to include, in light of the fact that 
+   GLib/Qt native stubs will probably also exist.
+
+ - 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)
+
+ - modify the auth protocol to also support other initial-handshake
+   type of information:
+
+   Perhaps the auth protocol should be able to negotiate a protocol 
+   version to the least-common-denominator between client and server?
+   Though in practice ever using this feature would be pretty tough, 
+   since protocol probably modifies the API. But we could have it there
+   as a safety net.
+
+ - re_align_field_recurse() in dbus-message.c is broken because it 
+   crashes on some types of header field values. security problem.
+
+ - modify the wire protocol to keep the args signature separate 
+   from the args themselves. Make the name of TYPE_CUSTOM part 
+   of the type signature, rather than part of the value.
+   Then you have the full typecheck in a single string.
+   See http://freedesktop.org/pipermail/dbus/2004-June/001169.html
+
+   Subnote: STRING_OR_NIL is wrong, doesn't work in C++ etc. ; should
+   not have done that. Use empty string or special string values or separate functions/signals 
+   or whatever instead.
+
+   Subnote: For recursive types, one approach is that "structs" are done as parens, 
+   so e.g. s(ii) is a string and struct { int; int; } etc. Type codes
+   then all have to be done as strings not single ints.
+   We could also put the type signature for the message body in a
+   header field.
+   An "any" type has the type string included in the value.
+
+ - 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.
+
+ - array lengths should probably be returned as size_t rather than int
+   (though they are kind of a pita to pass in as size_t with the 
+    varargs, so maybe not - what does glib do with g_object_get()?)
+
+ - finish dbus-glib-tool support for adding introspection 
+   data to GObject and autoexporting GObject using same
+
+ - 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?
+   You also still have to use some D-BUS functions such as 
+   dbus_message_get_args() which takes a DBusError. 
+   Probably we need to either fully encapsulate and hide 
+   dbus/dbus.h, or encapsulate it slightly less e.g. no 
+   GError. Or maybe it's as simple as "never return dbus_malloc() 
+   memory" and just fully encapsulate the get_args() type of 
+   stuff.
+
+ - dbus_gproxy or dbus_g_proxy?
+
+Might as Well for 1.0
+===
+
+ - Probably no point in a version number in the daemon name
+   (s/dbus-daemon-1/dbus-daemon/)
+
+ - add dbus_message_has_path(), maybe has_member/interface
+
+ - dbus_message_iter_init_array_iterator has "iter" and "iterator" 
+   in the same function name
+
+Can Be Post 1.0
+===
+
  - Property list feature on message bus (list of properties associated 
    with a connection). May also include message matching rules 
    that involve the properties of the source or destination
    connection.
 
- - Automatic service activation, should probably be done through a message flag.
-
  - Disconnecting the remote end on invalid UTF-8 is probably not a good 
-   idea. The definitiion of "valid" is slightly fuzzy. I think it might 
+   idea. The definition of "valid" is slightly fuzzy. I think it might 
    be better to just silently "fix" the UTF-8, or perhaps return an error.
 
    Owen says we should only validate the UTF-8 on dbus_message_get_string()
    (changing get_string to have an error return, and allowing a type error 
    as a possible return)
 
- - The convenience functions in dbus-bus.h should perhaps have
-   the signatures that they would have if they were autogenerated
-   stubs. e.g. the acquire service function. We should also evaluate 
-   which of these functions to include, in light of the fact that 
-   GLib/Qt native stubs will probably also exist.
-
  - 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.
@@ -57,75 +130,18 @@
    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)
+   If done post 1.0 will probably be an optional/ugly-API type 
+   of thing.
 
  - 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 such as protocol version
-
  - 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
-
- - re_align_field_recurse() in dbus-message.c is broken because it 
-   crashes on some types of header field values. security problem.
-
- - modify the wire protocol to keep the args signature separate 
-   from the args themselves. Make the name of TYPE_CUSTOM part 
-   of the type signature, rather than part of the value.
-   Then you have the full typecheck in a single string.
-   See http://freedesktop.org/pipermail/dbus/2004-June/001169.html
-
- - 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?
-   You also still have to use some D-BUS functions such as 
-   dbus_message_get_args() which takes a DBusError. 
-   Probably we need to either fully encapsulate and hide 
-   dbus/dbus.h, or encapsulate it slightly less e.g. no 
-   GError. Or maybe it's as simple as "never return dbus_malloc() 
-   memory" and just fully encapsulate the get_args() type of 
-   stuff.
-
- - 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.
-
- - array lengths should probably be returned as size_t rather than int
-   (though they are kind of a pita to pass in as size_t with the 
-    varargs, so maybe not - what does glib do with g_object_get()?)
-
  - recursive dispatch, see dbus_connection_dispatch()
 
- - Perhaps the auth protocol should be able to negotiate a protocol 
-   version to the least-common-denominator between client and server?
-   Though in practice ever using this feature would be pretty tough, 
-   since protocol probably modifies the API. But we could have it there
-   as a safety net.
-
- - STRING_OR_NIL is wrong, doesn't work in C++ etc. ; should not have done that.
-   Use empty string or special string values or separate functions/signals 
-   or whatever instead.
-
- - For recursive types, one approach is that "structs" are done as parens, 
-   so e.g. s(ii) is a string and struct { int; int; } etc. Type codes
-   then all have to be done as strings not single ints.
-   We could also put the type signature for the message body in a header field.
-   An "any" type has the type string included in the value.
-
  - do we need per-display activation; if so I'd like to do this by setting a
    "display ID" property on screen 0, with a GUID, and keying activation by 
    said GUID. Otherwise you get all kinds of unrobust
@@ -133,3 +149,4 @@
    to the display. If displays have a deterministic ID like this, you can 
    do per-display by simply including GUID in the service name.
 
+ - optimization and profiling!