dbus/doc TODO,1.64,1.65 dbus-specification.xml,1.27,1.28

[Havoc Pennington]

Update of /cvs/dbus/dbus/doc
In directory gabe:/tmp/cvs-serv30232/doc

Modified Files:
	TODO dbus-specification.xml 
Log Message:
some todo and spec tweaks


Index: TODO
===================================================================
RCS file: /cvs/dbus/dbus/doc/TODO,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -d -r1.64 -r1.65
--- TODO	12 Feb 2005 03:56:22 -0000	1.64
+++ TODO	12 Feb 2005 04:30:34 -0000	1.65
@@ -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 @@
    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 @@
    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 @@
 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 @@
    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 

Index: dbus-specification.xml
===================================================================
RCS file: /cvs/dbus/dbus/doc/dbus-specification.xml,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -d -r1.27 -r1.28
--- dbus-specification.xml	11 Feb 2005 03:37:03 -0000	1.27
+++ dbus-specification.xml	12 Feb 2005 04:30:34 -0000	1.28
@@ -2703,6 +2703,33 @@
         and if the client being activated fails to connect within that
         timeout, an error should be sent back.]
       </para>
+
+      <sect3 id="message-bus-starting-services-scope">
+        <title>Message Bus Service Scope</title>
+        <para>
+          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.
+        </para>
+        <para>
+          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
+          <literal>_DBUS_DISPLAY_ID</literal> 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.
+        </para>
+        <para>
+          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 <literal>_DBUS_DISPLAY_BUS_ADDRESS</literal> 
+          property on screen 0 of the display, pointing to this bus.
+        </para>
+      </sect3>
     </sect2>
 
     <sect2 id="message-bus-types">