Review and questions on the rest of the TODO items

[John (J5) Palmieri]

- Audit @todo and FIXME for security issues

Someone who is good at auditing for security should take the lead on
this.  Either way we should all give this a once over.

- The convenience functions in dbus-bus.h should perhaps have
   the signatures that they would have if they were autogenerated
   stubs. e.g. the acquire service function. We should also evaluate 
   which of these functions to include, in light of the fact that 
   GLib/Qt native stubs will probably also exist.

We need a discussion on this to evaluate what will be cut if anything.
Also can someone give me an example of the difference between what the
current signature looks like and what it would look like if
autogenerated? 

 - the "break loader" and valid/invalid message tests are all disabled;
   they need to be fixed and re-enabled with the new message args stuff.
   I think I want to drop the .message files thing and just have code
   that generates messages, more like the tests for
   dbus-marshal-recursive.c (this is mostly done now, just needs some
   cleanup)

Can someone elaborate on what cleanups are needed?

 - need to define bus behavior if you send a message to 
   yourself; is it an error, or allowed? If allowed, 
   we need to have a test for it in the test suite.

What are the advantages to allowing the bus to send messages back to the
caller?  Is it simpler to just make this an error (in which case I would
vote for this)?  The only case I could see this being needed is if
somehow a service got a reference back to itself through another
service.  Otherwise all calls should be made internally in my opinion.
This would discourage people from writing wastefully code on methods
that could just be called internally.

 - just before 1.0, try a HAVE_INT64=0 build and be sure it runs

Should we try this now or wait a bit?

 - dbus-pending-call.c has some API and thread safety issues to review

Anyone out there with vast thread knowledge want to tackle this?

 - Add test harness for selinux allow/deny cf. this message
   http://lists.freedesktop.org/archives/dbus/2005-April/002506.html

Similarly, anyone with SE-Linux experience want to take a look at this?

-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com