X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=doc%2FTODO;h=eb4e797ff6fcc61919e9194c3dc75605706dac45;hb=04c58b9e5fbdf3acc7565f989e5fcd11f0c23c57;hp=11374a98a24b894dc99660ff519256b866a3a0c6;hpb=54752a6d94a9d2cc4f488e8a3803e3b9bf9eda4b;p=platform%2Fupstream%2Fdbus.git diff --git a/doc/TODO b/doc/TODO index 11374a9..eb4e797 100644 --- a/doc/TODO +++ b/doc/TODO @@ -1,98 +1,78 @@ -Important for 1.0 +Important for 1.2 === - - - 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. - - - 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()?) + + - System bus activation + + - Windows port Important for 1.0 GLib Bindings === - - finish dbus-glib-tool support for adding introspection - data to GObject and autoexporting GObject using same + - Test point-to-point mode - - 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. + - Add support for getting sender - - dbus_gproxy_connect_signal() has to take a signature for the signal - so it can figure out how to invoke the callback, or we have to rely - on having introspection data. + - format_version in the object info doesn't look like it's handled correctly. The creator + of the object info should specify some fixed number per struct version; the library + should handle only specific numbers it knows about. There's no assumption that all + numbers >= the given one are compatible. The idea is that new versions of the lib + can offer totally different object info structs, but old versions + keep working. -Might as Well for 1.0 +Important for 1.0 Python bindings === - - Probably no point in a version number in the daemon name - (s/dbus-daemon-1/dbus-daemon/) + - Hammer down API + + - Fix removing of signals from the match tree - - add dbus_message_has_path(), maybe has_member/interface + - Fix refcounting and userdata lifecycles + + - Write a generic mainloop + +Might as Well for 1.0 +=== - - dbus_message_iter_init_array_iterator has "iter" and "iterator" - in the same function name + - protocol version in each message is pretty silly Can Be Post 1.0 === + - revamp dbus-launch a bit, + see http://lists.freedesktop.org/archives/dbus/2006-October/005906.html + for some thoughts. + + - clean up the creds issue on *BSD's in dbus/dbus-sysdeps-unix.c. + They should work as is but we need to rearange it to make it + clearer which method is being used. configure.in should + be fixed up to make that decition. + + - _dbus_connection_unref_unlocked() is essentially always broken because + the connection finalizer calls non-unlocked functions. One fix is to make + the finalizer run with the lock held, but since it calls out to the app that may + be pretty broken. More likely all the uses of unref_unlocked are just wrong. + + - if the GUID is obtained only during authentication, not in the address, + we could still share the connection + + - Allow a dbus_g_proxy_to_string()/g_object_to_string() that + would convert the proxy to an "IOR" and dbus_g_proxy_from_string() + that would decode; using these, dbus-glib users could avoid + DBusConnection entirely. Of course the same applies to other kinds + of binding. This would use dbus_connection_open()'s connection-sharing + feature to avoid massive proliferation of connections. + + - DBusWatchList/TimeoutList duplicate a lot of code, as do + protected_change_watch/protected_change_timeout in dbus-connection.c + and dbus-server.c. This could all be mopped up, cut-and-paste + fixed, code size reduced. + + - change .service files to allow Names=list in addition to Name=string + + - The message bus internal code still says "service" for + "name", "base service" for "unique name", "activate" for + "start"; would be nice to clean up. + - 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 @@ -102,14 +82,6 @@ Can Be Post 1.0 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) - - - 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. - - build and install the Doxygen manual in Makefile when --enable-docs - if you send the same message to multiple connections, the serial number @@ -142,6 +114,8 @@ Can Be Post 1.0 data could still be factored out into an internal "base class" perhaps. + - Keep convenience wrappers in sync with bus methods + - document the auth protocol as a set of states and transitions, and then reimplement it in those terms @@ -155,3 +129,27 @@ Can Be Post 1.0 do per-display by simply including GUID in the service name. - optimization and profiling! + + - Match rules aren't in the spec (probably a lot of methods on the bus + are not) + + - the "break loader" and valid/invalid message tests are all disabled; + they need to be fixed and re-enabled with the new message args stuff. + I think I want to drop the .message files thing and just have code + that generates messages, more like the tests for + dbus-marshal-recursive.c (this is mostly done now, just needs some + cleanup) + + - just before 1.0, try a HAVE_INT64=0 build and be sure it runs + + - Windows port needs recursive mutexes + +Should Be Post 1.0 +=== + + - look into supporting the concept of a "connection" generically + (what does this TODO item mean?) + + - test/name-test should be named test/with-bus or something like that + +