From a8b1cf0774493ef50dd2895be07d4811ef3bb6a6 Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Mon, 7 Jun 2004 21:02:23 +0000 Subject: 2004-06-07 Havoc Pennington * doc/TODO: remove auto-activation item since it's done; sort items by importance/milestone --- doc/TODO | 157 +++++++++++++++++++++++++++++++++++---------------------------- 1 file changed, 87 insertions(+), 70 deletions(-) (limited to 'doc') 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! -- cgit