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