mirror of
https://gitlab.freedesktop.org/dbus/dbus.git
synced 2025-12-25 11:40:10 +01:00
9e4450872a
* dbus/dbus-connection.c (dbus_connection_dispatch): always complete a pending call, don't run filters first. * glib/dbus-gproxy.c (dbus_g_proxy_end_call): change to use dbus_pending_call_steal_reply * dbus/dbus-pending-call.c (dbus_pending_call_block): just call _dbus_connection_block_pending_call (dbus_pending_call_get_reply): change to steal_reply and return a ref * dbus/dbus-connection.c (dbus_connection_send_with_reply_and_block): port to work in terms of DBusPendingCall (_dbus_connection_block_pending_call): replace block_for_reply with this
122 lines
4.6 KiB
Text
122 lines
4.6 KiB
Text
Important for 1.0
|
|
===
|
|
|
|
- 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 "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)
|
|
|
|
- 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.
|
|
|
|
- validate dict entry number of fields
|
|
|
|
- just before 1.0, try a HAVE_INT64=0 build and be sure it runs
|
|
|
|
- in dbus-keyring.c, enforce that the keyring dir is not
|
|
world readable/writable
|
|
|
|
- Ping isn't handled
|
|
|
|
- fix introspection format to handle all signatures
|
|
|
|
- make the mutex/condvar functions private
|
|
|
|
- dbus-pending-call.c has some API and thread safety issues to review
|
|
|
|
Important for 1.0 GLib Bindings
|
|
===
|
|
|
|
- finish dbus-glib-tool support for adding introspection
|
|
data to GObject and autoexporting GObject using same
|
|
|
|
- Need to make sure that dbus-glib.h never returns any
|
|
dbus_malloc() memory, only g_malloc().
|
|
dbus_g_proxy_end_call() is the major offender.
|
|
|
|
- DBusGProxy doesn't emit "destroy" when it should
|
|
|
|
Might as Well for 1.0
|
|
===
|
|
|
|
- add dbus_message_has_path(), maybe has_member/interface
|
|
|
|
- connection_open/connection_disconnect lacks symmetry, open/close
|
|
or connect/disconnect
|
|
|
|
- protocol version in each message is pretty silly
|
|
|
|
Can Be Post 1.0
|
|
===
|
|
|
|
- change .service files to allow Names=list in addition to Name=string
|
|
|
|
- The message bus internal code still says "service" for
|
|
"name", "base service" for "unique name", "activate" for
|
|
"start"; would be nice to clean up.
|
|
|
|
- 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.
|
|
|
|
- Disconnecting the remote end on invalid UTF-8 is probably not a good
|
|
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.
|
|
|
|
- build and install the Doxygen manual in Makefile when --enable-docs
|
|
|
|
- if you send the same message to multiple connections, the serial number
|
|
will only be right for one of them. Probably need to just write() the serial
|
|
number, rather than putting it in the DBusMessage, or something.
|
|
|
|
- perhaps the bus driver should have properties that reflect attributes
|
|
of the session, such as hostname, architecture, operating system,
|
|
etc. Could be useful for code that wants to special-case behavior
|
|
for a particular host or class of hosts, for example.
|
|
|
|
- currently the security policy stuff for messages to/from
|
|
the bus driver is kind of strange; basically it's hardcoded that
|
|
you can always talk to the driver, but the default config file
|
|
has rules for it anyway, or something. it's conceptually
|
|
screwy at the moment.
|
|
|
|
- when making a method call, if the call serial were globally unique,
|
|
we could forward the call serial along with any method calls made
|
|
as a result of the first method call, and allow reentrancy that was
|
|
strictly part of the call stack of said method call. But I don't
|
|
really see how to do this without making the user pass around the
|
|
call serial to all method calls all the time, or disallowing
|
|
async calls.
|
|
|
|
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.
|
|
|
|
- document the auth protocol as a set of states and transitions, and
|
|
then reimplement it in those terms
|
|
|
|
- recursive dispatch, see dbus_connection_dispatch()
|
|
|
|
- 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
|
|
string/hostname-based mess. per-screen is then done by appending screen number
|
|
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!
|