X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=doc%2FTODO;h=eb4e797ff6fcc61919e9194c3dc75605706dac45;hb=f5c7892c66e816d1046531e4d0e8d72e9e4c6b3f;hp=a35a6a41057a6bbcd7a02e0c674a6c5273b20d9c;hpb=72528d58bedae05a3eb3477bf19d6827f3b4675b;p=platform%2Fupstream%2Fdbus.git diff --git a/doc/TODO b/doc/TODO index a35a6a4..eb4e797 100644 --- a/doc/TODO +++ b/doc/TODO @@ -1,37 +1,87 @@ - - Probably no point in a version number in the daemon name - (s/dbus-daemon-1/dbus-daemon/) - - - 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. +Important for 1.2 +=== - - Activation needs some careful additional thinking-through. + - System bus activation + + - Windows port + +Important for 1.0 GLib Bindings +=== + + - Test point-to-point mode + + - Add support for getting sender + + - 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. + +Important for 1.0 Python bindings +=== + + - Hammer down API + + - Fix removing of signals from the match tree + + - Fix refcounting and userdata lifecycles + + - Write a generic mainloop + +Might as Well for 1.0 +=== + + - 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 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. - - build and install the Doxygen manual in Makefile when --enable-docs - if you send the same message to multiple connections, the serial number @@ -57,79 +107,49 @@ 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 + - 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 - - 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. + - recursive dispatch, see dbus_connection_dispatch() - - 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 + - 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 + string/hostname-based mess. per-screen is then done by appending screen number + to the display. If displays have a deterministic ID like this, you can + do per-display by simply including GUID in the service name. - - dbus_message_iter_init_array_iterator has "iter" and "iterator" - in the same function name + - optimization and profiling! - - 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. + - Match rules aren't in the spec (probably a lot of methods on the bus + are not) - - 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 "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) - - 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()?) + - just before 1.0, try a HAVE_INT64=0 build and be sure it runs - - recursive dispatch, see dbus_connection_dispatch() + - Windows port needs recursive mutexes - - 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. +Should Be Post 1.0 +=== - - 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. + - look into supporting the concept of a "connection" generically + (what does this TODO item mean?) - - 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. + - test/name-test should be named test/with-bus or something like that - - 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 - string/hostname-based mess. per-screen is then done by appending screen number - to the display. If displays have a deterministic ID like this, you can - do per-display by simply including GUID in the service name.