summaryrefslogtreecommitdiffstats
path: root/doc/TODO
diff options
context:
space:
mode:
authorHavoc Pennington <hp@redhat.com>2004-06-07 21:02:23 +0000
committerHavoc Pennington <hp@redhat.com>2004-06-07 21:02:23 +0000
commita8b1cf0774493ef50dd2895be07d4811ef3bb6a6 (patch)
treef949b6e8e20f66b29b2c83e484d676139e6e10bb /doc/TODO
parent72528d58bedae05a3eb3477bf19d6827f3b4675b (diff)
2004-06-07 Havoc Pennington <hp@redhat.com>
* doc/TODO: remove auto-activation item since it's done; sort items by importance/milestone
Diffstat (limited to 'doc/TODO')
-rw-r--r--doc/TODO157
1 files changed, 87 insertions, 70 deletions
diff --git a/doc/TODO b/doc/TODO
index a35a6a41..d89620bb 100644
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,5 +1,5 @@
- - Probably no point in a version number in the daemon name
- (s/dbus-daemon-1/dbus-daemon/)
+Important for 1.0
+===
- How we will handle DCOP needs sorting out. Among other things, we
need to check that service and service-ownership semantics map to DCOP
@@ -7,27 +7,100 @@
- Activation needs some careful additional thinking-through.
+ - Audit @todo and FIXME for security issues
+
+ - 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.
+
+ - the invalid messages in the test suite are all useless because
+ they are invalid for the wrong reasons due to protocol changes.
+ (Consider extending test suite to validate that they are
+ invalid for right reason, e.g. an "INVALID_ERROR Foo" line
+ in the message files)
+
+ - modify the auth protocol to also support other initial-handshake
+ type of information:
+
+ Perhaps the auth protocol should be able to negotiate a protocol
+ version to the least-common-denominator between client and server?
+ Though in practice ever using this feature would be pretty tough,
+ since protocol probably modifies the API. But we could have it there
+ as a safety net.
+
+ - re_align_field_recurse() in dbus-message.c is broken because it
+ crashes on some types of header field values. security problem.
+
+ - modify the wire protocol to keep the args signature separate
+ from the args themselves. Make the name of TYPE_CUSTOM part
+ of the type signature, rather than part of the value.
+ Then you have the full typecheck in a single string.
+ See http://freedesktop.org/pipermail/dbus/2004-June/001169.html
+
+ Subnote: STRING_OR_NIL is wrong, doesn't work in C++ etc. ; should
+ not have done that. Use empty string or special string values or separate functions/signals
+ or whatever instead.
+
+ Subnote: For recursive types, one approach is that "structs" are done as parens,
+ so e.g. s(ii) is a string and struct { int; int; } etc. Type codes
+ then all have to be done as strings not single ints.
+ We could also put the type signature for the message body in a
+ header field.
+ An "any" type has the type string included in the value.
+
+ - 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.
+
+ - array lengths should probably be returned as size_t rather than int
+ (though they are kind of a pita to pass in as size_t with the
+ varargs, so maybe not - what does glib do with g_object_get()?)
+
+ - finish dbus-glib-tool support for adding introspection
+ data to GObject and autoexporting GObject using same
+
+ - the GLib bindings varargs take DBUS_TYPE_WHATEVER and
+ return stuff allocated with dbus_malloc(); should this
+ be made more "G" at some expense in code duplication?
+ You also still have to use some D-BUS functions such as
+ dbus_message_get_args() which takes a DBusError.
+ Probably we need to either fully encapsulate and hide
+ dbus/dbus.h, or encapsulate it slightly less e.g. no
+ GError. Or maybe it's as simple as "never return dbus_malloc()
+ memory" and just fully encapsulate the get_args() type of
+ stuff.
+
+ - dbus_gproxy or dbus_g_proxy?
+
+Might as Well for 1.0
+===
+
+ - Probably no point in a version number in the daemon name
+ (s/dbus-daemon-1/dbus-daemon/)
+
+ - add dbus_message_has_path(), maybe has_member/interface
+
+ - dbus_message_iter_init_array_iterator has "iter" and "iterator"
+ in the same function name
+
+Can Be Post 1.0
+===
+
- 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.
- - 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
+ idea. The definition 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)
- - 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.
-
- assorted _-prefixed symbols in libdbus aren't actually used by
libdbus, only by the message bus. These bloat up the library
size. Not sure how to fix, really.
@@ -57,75 +130,18 @@
call serial to all method calls all the time, or disallowing
async calls.
- - the invalid messages in the test suite are all useless because
- they are invalid for the wrong reasons due to protocol changes.
- (Consider extending test suite to validate that they are
- invalid for right reason, e.g. an "INVALID_ERROR Foo" line
- in the message files)
+ If done post 1.0 will probably be an optional/ugly-API type
+ of thing.
- I don't want to introduce DBusObject, but refcounting and object
data could still be factored out into an internal "base class"
perhaps.
- - modify the auth protocol to also support other initial-handshake
- type of information such as protocol version
-
- document the auth protocol as a set of states and transitions, and
then reimplement it in those terms
- - dbus_gproxy or dbus_g_proxy?
-
- - add dbus_message_has_path(), maybe has_member/interface
-
- - re_align_field_recurse() in dbus-message.c is broken because it
- crashes on some types of header field values. security problem.
-
- - modify the wire protocol to keep the args signature separate
- from the args themselves. Make the name of TYPE_CUSTOM part
- of the type signature, rather than part of the value.
- Then you have the full typecheck in a single string.
- See http://freedesktop.org/pipermail/dbus/2004-June/001169.html
-
- - dbus_message_iter_init_array_iterator has "iter" and "iterator"
- in the same function name
-
- - the GLib bindings varargs take DBUS_TYPE_WHATEVER and
- return stuff allocated with dbus_malloc(); should this
- be made more "G" at some expense in code duplication?
- You also still have to use some D-BUS functions such as
- dbus_message_get_args() which takes a DBusError.
- Probably we need to either fully encapsulate and hide
- dbus/dbus.h, or encapsulate it slightly less e.g. no
- GError. Or maybe it's as simple as "never return dbus_malloc()
- memory" and just fully encapsulate the get_args() type of
- stuff.
-
- - 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.
-
- - array lengths should probably be returned as size_t rather than int
- (though they are kind of a pita to pass in as size_t with the
- varargs, so maybe not - what does glib do with g_object_get()?)
-
- recursive dispatch, see dbus_connection_dispatch()
- - Perhaps the auth protocol should be able to negotiate a protocol
- version to the least-common-denominator between client and server?
- Though in practice ever using this feature would be pretty tough,
- since protocol probably modifies the API. But we could have it there
- as a safety net.
-
- - STRING_OR_NIL is wrong, doesn't work in C++ etc. ; should not have done that.
- Use empty string or special string values or separate functions/signals
- or whatever instead.
-
- - For recursive types, one approach is that "structs" are done as parens,
- so e.g. s(ii) is a string and struct { int; int; } etc. Type codes
- then all have to be done as strings not single ints.
- We could also put the type signature for the message body in a header field.
- An "any" type has the type string included in the value.
-
- do we need per-display activation; if so I'd like to do this by setting a
"display ID" property on screen 0, with a GUID, and keying activation by
said GUID. Otherwise you get all kinds of unrobust
@@ -133,3 +149,4 @@
to the display. If displays have a deterministic ID like this, you can
do per-display by simply including GUID in the service name.
+ - optimization and profiling!