2 - Service and message names should be more carefully restricted;
3 they should have a max length, may not be an empty string,
4 and perhaps should not be allowed to be a glob such as "*" since
5 the config file could conveniently use such notation.
7 Suggest requiring length > 0, length < max,
8 name contains at least one ".", no initial ".", and valid UTF-8.
9 That would prohibit plain "*" but not "foo.bar.baz.operator*"
11 For maximum convenience from all programming languages, we could go
12 further and just categorically ban nearly all non-alphanumeric
15 - Message matching rules (so broadcasts can be filtered) need sorting
18 - How we will handle DCOP needs sorting out. Among other things, we
19 need to check that service and service-ownership semantics map to DCOP
22 - Activation needs some careful additional thinking-through.
24 - Recursive/composite/etc. types and associated API, see mailing list.
26 - Configuration file (working on that now)
28 - Property list feature on message bus (list of properties associated
29 with a connection). May also include message matching rules
30 that involve the properties of the source or destination
33 - Implement all the needed resource limits to keep clients from
34 killing the message bus.
36 - Automatic service activation, should probably be done through a message flag.
38 - Disconnecting the remote end on invalid UTF-8 is probably not a good
39 idea. The definitiion of "valid" is slightly fuzzy. I think it might
40 be better to just silently "fix" the UTF-8, or perhaps return an error.
42 Owen says we should only validate the UTF-8 on dbus_message_get_string()
43 (changing get_string to have an error return, and allowing a type error
46 - We might consider returning a "no such operation" error in dbus-connection.c
47 for unhandled messages.
49 - Abstract the user database, so you can use something other than the system password
52 - The convenience functions in dbus-bus.h should perhaps have
53 the signatures that they would have if they were autogenerated
54 stubs. e.g. the acquire service function. We should also evaluate
55 which of these functions to include, in light of the fact that
56 GLib/Qt native stubs will probably also exist.
58 - The message handler interface needs rethinking, perhaps handlers should be able
59 to return an error that automatically gets turned into a message; most likely
60 some basic spec'ing out of the GLib/Qt level stubs/skels stuff will be
61 needed to understand the right approach.
63 - sync up DBusWatch and DBusTimeout so that handle_watch() is a method on DBusWatch
64 similar to the way timeouts work
66 - there are various bits of code to manage ref/unref of data slots, that should
67 be merged into a generic facility
69 - add _dbus_return_if_fail, _dbus_return_val_if_fail() and use on public entry
70 points in place of _dbus_assert(). Add --disable-checks to control whether these
73 - assorted _-prefixed symbols in libdbus aren't actually used by
74 libdbus, only by the message bus. These bloat up the library
75 size. Not sure how to fix, really.
77 - dbus_error_has_name(), dbus_message_name_is()
79 - add DBUS_TYPE_INT64 ?
81 - if you send a message to a service then block for reply, and the service exits/crashes
82 after the message bus has processed your message but before the service has replied,
83 it would be nice if the message bus sent you an error reply.
85 - We have a limit on the number of messages a connection can send, but
86 not on how many can be buffered for a given connection.
88 - make client serial and reply serial unsigned and add dbus_message_get_is_reply()