From 03a4a5a976f83e822eb9cc4749a587abe43592d7 Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Sat, 12 Feb 2005 04:30:34 +0000 Subject: some todo and spec tweaks --- doc/TODO | 25 ++++--------------------- doc/dbus-specification.xml | 27 +++++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 21 deletions(-) (limited to 'doc') diff --git a/doc/TODO b/doc/TODO index 95e77107..38ed3b70 100644 --- a/doc/TODO +++ b/doc/TODO @@ -1,14 +1,6 @@ Important for 1.0 === - - change .service files to have Names=list rather than Name=string - - - How we will handle DCOP needs sorting out. Among other things, we - need to check that service and service-ownership semantics map to DCOP - reasonably well. - - - Activation needs some careful additional thinking-through. - - Audit @todo and FIXME for security issues - The convenience functions in dbus-bus.h should perhaps have @@ -21,7 +13,8 @@ Important for 1.0 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 + 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, @@ -46,10 +39,6 @@ Important for 1.0 GLib Bindings dbus_malloc() memory, only g_malloc(). dbus_g_proxy_end_call() is the major offender. - - DBusGProxy signals feature is a complete fiasco; - right now the problem is that it dynamically creates - signals on the global DBusGProxy class and never frees them - - DBusGProxy doesn't emit "destroy" when it should Might as Well for 1.0 @@ -65,6 +54,8 @@ Might as Well for 1.0 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. @@ -78,14 +69,6 @@ Can Be Post 1.0 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) - - - 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. - - build and install the Doxygen manual in Makefile when --enable-docs - if you send the same message to multiple connections, the serial number diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index b56e0fc5..a9492b96 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -2703,6 +2703,33 @@ and if the client being activated fails to connect within that timeout, an error should be sent back.] + + + Message Bus Service Scope + + The "scope" of a service is its "per-", such as per-session, + per-machine, per-home-directory, or per-display. The reference + implementation doesn't yet support starting services in a different + scope from the message bus itself. So e.g. if you start a service + on the session bus its scope is per-session. + + + We could add an optional scope to a bus name. For example, for + per-(display,session pair), we could have a unique ID for each display + generated automatically at login and set on screen 0 by executing a + special "set display ID" binary. The ID would be stored in a + _DBUS_DISPLAY_ID property and would be a string of + random bytes. This ID would then be used to scope names. + Starting/locating a service could be done by ID-name pair rather than + only by name. + + + Contrast this with a per-display scope. To achieve that, we would + want a single bus spanning all sessions using a given display. + So we might set a _DBUS_DISPLAY_BUS_ADDRESS + property on screen 0 of the display, pointing to this bus. + + -- cgit