155 lines
5.8 KiB
Text
155 lines
5.8 KiB
Text
Important for 1.2
|
|
===
|
|
|
|
- System bus activation
|
|
|
|
- Windows port
|
|
|
|
Important for 1.0 GLib Bindings
|
|
===
|
|
|
|
- Test point-to-point mode
|
|
|
|
- Add support for getting sender
|
|
|
|
- format_version in the object info doesn't look like it's handled correctly. The creator
|
|
of the object info should specify some fixed number per struct version; the library
|
|
should handle only specific numbers it knows about. There's no assumption that all
|
|
numbers >= the given one are compatible. The idea is that new versions of the lib
|
|
can offer totally different object info structs, but old versions
|
|
keep working.
|
|
|
|
Important for 1.0 Python bindings
|
|
===
|
|
|
|
- Hammer down API
|
|
|
|
- Fix removing of signals from the match tree
|
|
|
|
- Fix refcounting and userdata lifecycles
|
|
|
|
- Write a generic mainloop
|
|
|
|
Might as Well for 1.0
|
|
===
|
|
|
|
- protocol version in each message is pretty silly
|
|
|
|
Can Be Post 1.0
|
|
===
|
|
|
|
- revamp dbus-launch a bit,
|
|
see http://lists.freedesktop.org/archives/dbus/2006-October/005906.html
|
|
for some thoughts.
|
|
|
|
- clean up the creds issue on *BSD's in dbus/dbus-sysdeps-unix.c.
|
|
They should work as is but we need to rearange it to make it
|
|
clearer which method is being used. configure.in should
|
|
be fixed up to make that decition.
|
|
|
|
- _dbus_connection_unref_unlocked() is essentially always broken because
|
|
the connection finalizer calls non-unlocked functions. One fix is to make
|
|
the finalizer run with the lock held, but since it calls out to the app that may
|
|
be pretty broken. More likely all the uses of unref_unlocked are just wrong.
|
|
|
|
- if the GUID is obtained only during authentication, not in the address,
|
|
we could still share the connection
|
|
|
|
- Allow a dbus_g_proxy_to_string()/g_object_to_string() that
|
|
would convert the proxy to an "IOR" and dbus_g_proxy_from_string()
|
|
that would decode; using these, dbus-glib users could avoid
|
|
DBusConnection entirely. Of course the same applies to other kinds
|
|
of binding. This would use dbus_connection_open()'s connection-sharing
|
|
feature to avoid massive proliferation of connections.
|
|
|
|
- DBusWatchList/TimeoutList duplicate a lot of code, as do
|
|
protected_change_watch/protected_change_timeout in dbus-connection.c
|
|
and dbus-server.c. This could all be mopped up, cut-and-paste
|
|
fixed, code size reduced.
|
|
|
|
- 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.
|
|
|
|
- Keep convenience wrappers in sync with bus methods
|
|
|
|
- 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!
|
|
|
|
- Match rules aren't in the spec (probably a lot of methods on the bus
|
|
are not)
|
|
|
|
- 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)
|
|
|
|
- just before 1.0, try a HAVE_INT64=0 build and be sure it runs
|
|
|
|
- Windows port needs recursive mutexes
|
|
|
|
Should Be Post 1.0
|
|
===
|
|
|
|
- look into supporting the concept of a "connection" generically
|
|
(what does this TODO item mean?)
|
|
|
|
- test/name-test should be named test/with-bus or something like that
|
|
|
|
|