doc/TODO

   1 Important for 1.0
   2 ===
   3
   4  - change .service files to have Names=list rather than Name=string
   5
   6  - How we will handle DCOP needs sorting out. Among other things, we
   7    need to check that service and service-ownership semantics map to DCOP
   8    reasonably well.
   9
  10  - Activation needs some careful additional thinking-through.
  11
  12  - Audit @todo and FIXME for security issues
  13
  14  - The convenience functions in dbus-bus.h should perhaps have
  15    the signatures that they would have if they were autogenerated
  16    stubs. e.g. the acquire service function. We should also evaluate
  17    which of these functions to include, in light of the fact that
  18    GLib/Qt native stubs will probably also exist.
  19
  20  - the "break loader" and valid/invalid message tests are all disabled;
  21    they need to be fixed and re-enabled with the new message args stuff.
  22    I think I want to drop the .message files thing and just have code
  23    that generates messages, more like the tests for
  24    dbus-marshal-recursive.c
  25
  26  - need to define bus behavior if you send a message to
  27    yourself; is it an error, or allowed? If allowed,
  28    we need to have a test for it in the test suite.
  29
  30  - validate dict entry number of fields
  31
  32  - just before 1.0, try a HAVE_INT64=0 build and be sure it runs
  33
  34  - in dbus-keyring.c, enforce that the keyring dir is not
  35    world readable/writable
  36
  37  - the "server addresses" section of the spec is busted; need to
  38    support escaping in the addresses, be sure multiple addresses
  39    in one env variable work, etc.
  40
  41  - Ping isn't handled
  42
  43 Important for 1.0 GLib Bindings
  44 ===
  45
  46  - finish dbus-glib-tool support for adding introspection
  47    data to GObject and autoexporting GObject using same
  48
  49  - Need to make sure that dbus-glib.h never returns any
  50    dbus_malloc() memory, only g_malloc().
  51    dbus_g_proxy_end_call() is the major offender.
  52
  53  - DBusGProxy signals feature is a complete fiasco;
  54    right now the problem is that it dynamically creates
  55    signals on the global DBusGProxy class and never frees them
  56
  57  - DBusGProxy doesn't emit "destroy" when it should
  58
  59 Might as Well for 1.0
  60 ===
  61
  62  - add dbus_message_has_path(), maybe has_member/interface
  63
  64  - connection_open/connection_disconnect lacks symmetry, open/close
  65    or connect/disconnect
  66
  67  - protocol version in each message is pretty silly
  68
  69 Can Be Post 1.0
  70 ===
  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    Owen says we should only validate the UTF-8 on dbus_message_get_string()
  86    (changing get_string to have an error return, and allowing a type error
  87    as a possible return)
  88
  89  - assorted _-prefixed symbols in libdbus aren't actually used by
  90    libdbus, only by the message bus. These bloat up the library
  91    size. Not sure how to fix, really.
  92
  93  - build and install the Doxygen manual in Makefile when --enable-docs
  94
  95  - if you send the same message to multiple connections, the serial number
  96    will only be right for one of them. Probably need to just write() the serial
  97    number, rather than putting it in the DBusMessage, or something.
  98
  99  - perhaps the bus driver should have properties that reflect attributes
 100    of the session, such as hostname, architecture, operating system,
 101    etc. Could be useful for code that wants to special-case behavior
 102    for a particular host or class of hosts, for example.
 103
 104  - currently the security policy stuff for messages to/from
 105    the bus driver is kind of strange; basically it's hardcoded that
 106    you can always talk to the driver, but the default config file
 107    has rules for it anyway, or something. it's conceptually
 108    screwy at the moment.
 109
 110  - when making a method call, if the call serial were globally unique,
 111    we could forward the call serial along with any method calls made
 112    as a result of the first method call, and allow reentrancy that was
 113    strictly part of the call stack of said method call. But I don't
 114    really see how to do this without making the user pass around the
 115    call serial to all method calls all the time, or disallowing
 116    async calls.
 117
 118    If done post 1.0 will probably be an optional/ugly-API type
 119    of thing.
 120
 121  - I don't want to introduce DBusObject, but refcounting and object
 122    data could still be factored out into an internal "base class"
 123    perhaps.
 124
 125  - document the auth protocol as a set of states and transitions, and
 126    then reimplement it in those terms
 127
 128  - recursive dispatch, see dbus_connection_dispatch()
 129
 130  - do we need per-display activation; if so I'd like to do this by setting a
 131    "display ID" property on screen 0, with a GUID, and keying activation by
 132    said GUID. Otherwise you get all kinds of unrobust
 133    string/hostname-based mess. per-screen is then done by appending screen number
 134    to the display. If displays have a deterministic ID like this, you can
 135    do per-display by simply including GUID in the service name.
 136
 137  - optimization and profiling!