2006-07-17 John (J5) Palmieri <johnp@redhat.com>
+ * doc/TODO:
+ * dbus/dbus-bus.c:
+ * dbus-errors.c:
+ * dbus/dbus-marshal-validate.c:
+ Removed TODO items which were fixed or are no longer relevent
+
+2006-07-17 John (J5) Palmieri <johnp@redhat.com>
+
* dbus-qt4-1.pc.in, dbus-sharp.pc.in:
Remove stray files from the stripped bindings
* connection to the bus already exists, then that connection is
* returned. Caller owns a reference to the bus.
*
- * @todo alex thinks we should nullify the connection when we get a disconnect-message.
- *
* @param type bus type
* @param error address where an error can be returned.
* @returns a DBusConnection with new ref
* (last-started-wins) or be queued up (first-started-wins) according
* to whether #DBUS_NAME_FLAG_ALLOW_REPLACEMENT was given.
*
- * @todo this all seems sort of broken. Shouldn't the flags be a property
- * of the name, not the app requesting the name? What are the use-cases
- * other than the "text editor" thing and how are we supporting them?
- *
* @param connection the connection
* @param name the name to request
* @param flags flags
* message will be deduced from the name. If the error name is unknown
* to D-BUS the default message will be totally useless, though.
*
- * @todo should be called dbus_error_set_const()
- *
* @param error the error.
* @param name the error name (not copied!!!)
* @param message the error message (not copied!!!)
* If no memory can be allocated for the error message,
* an out-of-memory error message will be set instead.
*
- * @todo should be called dbus_error_set()
- *
* @param error the error.
* @param name the error name
* @param format printf-style format string.
* The range passed in should NOT include the terminating
* nul/DBUS_TYPE_INVALID.
*
- * @todo verify that dict entries have exactly two fields
- *
- * @todo require that dict entries are in an array
- *
* @param type_str the string
* @param type_pos where the typecodes start
* @param len length of typecodes
-Important for 0.90 freeze
-===
-
-- Audit @todo and FIXME for security issues that require API/ABI changes
-
-- dbus-pending-call.c has some API and thread safety issues to review.
- DBusPendingCall is used from multiple threads with no locks.
- Either DBusConnection's lock has to protect all associated pending
- call (means pending->connection can't ever be set to null) or
- or DBusPendingCall needs its own lock
- http://lists.freedesktop.org/archives/dbus/2006-June/004945.html
-
Important for 1.0
===