Emeric Vigier | 2f62582 | 2012-08-06 11:09:52 -0400 | [diff] [blame] | 1 | Important for 1.2 |
| 2 | === |
| 3 | |
| 4 | - System bus activation |
| 5 | |
| 6 | - Windows port |
| 7 | |
| 8 | Important for 1.0 GLib Bindings |
| 9 | === |
| 10 | |
| 11 | - Test point-to-point mode |
| 12 | |
| 13 | - Add support for getting sender |
| 14 | |
| 15 | - format_version in the object info doesn't look like it's handled correctly. The creator |
| 16 | of the object info should specify some fixed number per struct version; the library |
| 17 | should handle only specific numbers it knows about. There's no assumption that all |
| 18 | numbers >= the given one are compatible. The idea is that new versions of the lib |
| 19 | can offer totally different object info structs, but old versions |
| 20 | keep working. |
| 21 | |
| 22 | Important for 1.0 Python bindings |
| 23 | === |
| 24 | |
| 25 | - Hammer down API |
| 26 | |
| 27 | - Fix removing of signals from the match tree |
| 28 | |
| 29 | - Fix refcounting and userdata lifecycles |
| 30 | |
| 31 | - Write a generic mainloop |
| 32 | |
| 33 | Might as Well for 1.0 |
| 34 | === |
| 35 | |
| 36 | - protocol version in each message is pretty silly |
| 37 | |
| 38 | Can Be Post 1.0 |
| 39 | === |
| 40 | |
| 41 | - revamp dbus-launch a bit, |
| 42 | see http://lists.freedesktop.org/archives/dbus/2006-October/005906.html |
| 43 | for some thoughts. |
| 44 | |
| 45 | - clean up the creds issue on *BSD's in dbus/dbus-sysdeps-unix.c. |
| 46 | They should work as is but we need to rearange it to make it |
| 47 | clearer which method is being used. configure.in should |
| 48 | be fixed up to make that decition. |
| 49 | |
| 50 | - _dbus_connection_unref_unlocked() is essentially always broken because |
| 51 | the connection finalizer calls non-unlocked functions. One fix is to make |
| 52 | the finalizer run with the lock held, but since it calls out to the app that may |
| 53 | be pretty broken. More likely all the uses of unref_unlocked are just wrong. |
| 54 | |
| 55 | - if the GUID is obtained only during authentication, not in the address, |
| 56 | we could still share the connection |
| 57 | |
| 58 | - Allow a dbus_g_proxy_to_string()/g_object_to_string() that |
| 59 | would convert the proxy to an "IOR" and dbus_g_proxy_from_string() |
| 60 | that would decode; using these, dbus-glib users could avoid |
| 61 | DBusConnection entirely. Of course the same applies to other kinds |
| 62 | of binding. This would use dbus_connection_open()'s connection-sharing |
| 63 | feature to avoid massive proliferation of connections. |
| 64 | |
| 65 | - DBusWatchList/TimeoutList duplicate a lot of code, as do |
| 66 | protected_change_watch/protected_change_timeout in dbus-connection.c |
| 67 | and dbus-server.c. This could all be mopped up, cut-and-paste |
| 68 | fixed, code size reduced. |
| 69 | |
| 70 | - change .service files to allow Names=list in addition to Name=string |
| 71 | |
| 72 | - The message bus internal code still says "service" for |
| 73 | "name", "base service" for "unique name", "activate" for |
| 74 | "start"; would be nice to clean up. |
| 75 | |
| 76 | - Property list feature on message bus (list of properties associated |
| 77 | with a connection). May also include message matching rules |
| 78 | that involve the properties of the source or destination |
| 79 | connection. |
| 80 | |
| 81 | - Disconnecting the remote end on invalid UTF-8 is probably not a good |
| 82 | idea. The definition of "valid" is slightly fuzzy. I think it might |
| 83 | be better to just silently "fix" the UTF-8, or perhaps return an error. |
| 84 | |
| 85 | - build and install the Doxygen manual in Makefile when --enable-docs |
| 86 | |
| 87 | - if you send the same message to multiple connections, the serial number |
| 88 | will only be right for one of them. Probably need to just write() the serial |
| 89 | number, rather than putting it in the DBusMessage, or something. |
| 90 | |
| 91 | - perhaps the bus driver should have properties that reflect attributes |
| 92 | of the session, such as hostname, architecture, operating system, |
| 93 | etc. Could be useful for code that wants to special-case behavior |
| 94 | for a particular host or class of hosts, for example. |
| 95 | |
| 96 | - currently the security policy stuff for messages to/from |
| 97 | the bus driver is kind of strange; basically it's hardcoded that |
| 98 | you can always talk to the driver, but the default config file |
| 99 | has rules for it anyway, or something. it's conceptually |
| 100 | screwy at the moment. |
| 101 | |
| 102 | - when making a method call, if the call serial were globally unique, |
| 103 | we could forward the call serial along with any method calls made |
| 104 | as a result of the first method call, and allow reentrancy that was |
| 105 | strictly part of the call stack of said method call. But I don't |
| 106 | really see how to do this without making the user pass around the |
| 107 | call serial to all method calls all the time, or disallowing |
| 108 | async calls. |
| 109 | |
| 110 | If done post 1.0 will probably be an optional/ugly-API type |
| 111 | of thing. |
| 112 | |
| 113 | - I don't want to introduce DBusObject, but refcounting and object |
| 114 | data could still be factored out into an internal "base class" |
| 115 | perhaps. |
| 116 | |
| 117 | - Keep convenience wrappers in sync with bus methods |
| 118 | |
| 119 | - document the auth protocol as a set of states and transitions, and |
| 120 | then reimplement it in those terms |
| 121 | |
| 122 | - recursive dispatch, see dbus_connection_dispatch() |
| 123 | |
| 124 | - do we need per-display activation; if so I'd like to do this by setting a |
| 125 | "display ID" property on screen 0, with a GUID, and keying activation by |
| 126 | said GUID. Otherwise you get all kinds of unrobust |
| 127 | string/hostname-based mess. per-screen is then done by appending screen number |
| 128 | to the display. If displays have a deterministic ID like this, you can |
| 129 | do per-display by simply including GUID in the service name. |
| 130 | |
| 131 | - optimization and profiling! |
| 132 | |
| 133 | - Match rules aren't in the spec (probably a lot of methods on the bus |
| 134 | are not) |
| 135 | |
| 136 | - the "break loader" and valid/invalid message tests are all disabled; |
| 137 | they need to be fixed and re-enabled with the new message args stuff. |
| 138 | I think I want to drop the .message files thing and just have code |
| 139 | that generates messages, more like the tests for |
| 140 | dbus-marshal-recursive.c (this is mostly done now, just needs some |
| 141 | cleanup) |
| 142 | |
| 143 | - just before 1.0, try a HAVE_INT64=0 build and be sure it runs |
| 144 | |
| 145 | - Windows port needs recursive mutexes |
| 146 | |
| 147 | Should Be Post 1.0 |
| 148 | === |
| 149 | |
| 150 | - look into supporting the concept of a "connection" generically |
| 151 | (what does this TODO item mean?) |
| 152 | |
| 153 | - test/name-test should be named test/with-bus or something like that |
| 154 | |
| 155 | |