- Service and message names should be more carefully restricted;
   they should have a max length, may not be an empty string, 
   and perhaps should not be allowed to be a glob such as "*" since
   the config file could conveniently use such notation. 

   Suggest requiring length > 0, length < max, 
   name contains at least one ".", no initial ".", and valid UTF-8. 
   That would prohibit plain "*" but not "foo.bar.baz.operator*"

   For maximum convenience from all programming languages, we could go
   further and just categorically ban nearly all non-alphanumeric
   characters.

 - Message matching rules (so broadcasts can be filtered) need sorting
   out.

 - How we will handle DCOP needs sorting out. Among other things, we
   need to check that service and service-ownership semantics map to DCOP 
   reasonably well.

 - Activation needs some careful additional thinking-through.

 - Recursive/composite/etc. types and associated API, see mailing list.

 - Configuration file (working on that now)

 - 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.

 - Implement all the needed resource limits to keep clients from
   killing the message bus.

 - Automatic service activation, should probably be done through a message flag.

 - Disconnecting the remote end on invalid UTF-8 is probably not a good 
   idea. The definitiion of "valid" is slightly fuzzy. I think it might 
   be better to just silently "fix" the UTF-8, or perhaps return an error.

   Owen says we should only validate the UTF-8 on dbus_message_get_string()
   (changing get_string to have an error return, and allowing a type error 
   as a possible return)

 - We might consider returning a "no such operation" error in dbus-connection.c 
   for unhandled messages.

 - Abstract the user database, so you can use something other than the system password 
   database.