diff options
Diffstat (limited to 'src/3rd_party/dbus-1.7.8/doc/TODO')
-rw-r--r-- | src/3rd_party/dbus-1.7.8/doc/TODO | 155 |
1 files changed, 0 insertions, 155 deletions
diff --git a/src/3rd_party/dbus-1.7.8/doc/TODO b/src/3rd_party/dbus-1.7.8/doc/TODO deleted file mode 100644 index eb4e797ff6..0000000000 --- a/src/3rd_party/dbus-1.7.8/doc/TODO +++ /dev/null @@ -1,155 +0,0 @@ -Important for 1.2 -=== - - - 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. - - - Disconnecting the remote end on invalid UTF-8 is probably not a good - 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. - - - build and install the Doxygen manual in Makefile when --enable-docs - - - if you send the same message to multiple connections, the serial number - will only be right for one of them. Probably need to just write() the serial - number, rather than putting it in the DBusMessage, or something. - - - perhaps the bus driver should have properties that reflect attributes - of the session, such as hostname, architecture, operating system, - etc. Could be useful for code that wants to special-case behavior - for a particular host or class of hosts, for example. - - - currently the security policy stuff for messages to/from - the bus driver is kind of strange; basically it's hardcoded that - you can always talk to the driver, but the default config file - has rules for it anyway, or something. it's conceptually - screwy at the moment. - - - 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. - - 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. - - - 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 - - - recursive dispatch, see dbus_connection_dispatch() - - - 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. - - - 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 - - |