From f3ef868ebd07b4034546b2bd48bb198fc2c34ba5 Mon Sep 17 00:00:00 2001 From: Will Thompson Date: Thu, 30 Sep 2010 16:12:59 +0100 Subject: Split well-known CM parameters into a type --- spec/Connection_Manager.xml | 89 ++++++++++++++++++++++++++------------------- 1 file changed, 51 insertions(+), 38 deletions(-) (limited to 'spec/Connection_Manager.xml') diff --git a/spec/Connection_Manager.xml b/spec/Connection_Manager.xml index 709a9b95..af328359 100644 --- a/spec/Connection_Manager.xml +++ b/spec/Connection_Manager.xml @@ -273,7 +273,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. A dictionary mapping parameter names to values of the appropriate type, as indicated by GetParameters - and the above well-known list. + and the well-known list of names and value types documented on the + Connection_Parameter_Name type. @@ -307,7 +308,54 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.To request values for these parameters from the user, a client must have prior knowledge of the meaning of the parameter names, so the - following well-known names and types should be used where appropriate:

+ well-known names and types defined by the + Connection_Parameter_Name type should be used where + appropriate.

+ +

Connection manager authors SHOULD avoid introducing parameters + whose default values would not be serializable in a + .manager file.

+ + +

The same serialization format is used in Mission Control + to store accounts.

+ + +

Every successful RequestConnection call will cause the emission of a + NewConnection signal for the same newly + created connection. The + requester can use the returned object path and service name + independently of the emission of that signal. In that case this signal + emission is most useful for, e.g. other processes that are monitoring + the creation of new connections.

+ + + + + + The requested protocol is not supported by this manager + + + + + The requested connection already appears to exist + + + + + Unrecognised connection parameters + + + + + + + +

Well-known connection parameter names, along with their expected + type. Where possible, connection managers should use names and types + from this list in the Parameters that may be passed + to RequestConnection.

account (s)
@@ -358,43 +406,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.0 to disable such pings.
- -

Connection manager authors SHOULD avoid introducing parameters - whose default values would not be serializable in a - .manager file.

- - -

The same serialization format is used in Mission Control - to store accounts.

- - -

Every successful RequestConnection call will cause the emission of a - NewConnection signal for the same newly - created connection. The - requester can use the returned object path and service name - independently of the emission of that signal. In that case this signal - emission is most useful for, e.g. other processes that are monitoring - the creation of new connections.

 - - - - - The requested protocol is not supported by this manager - - - - - The requested connection already appears to exist - - - - - Unrecognised connection parameters - - - - + -- cgit v1.2.3