From 848a1238a615f784d826fb74359418e13e3b40f0 Mon Sep 17 00:00:00 2001 From: Tomas Frydrych Date: Thu, 24 Feb 2011 16:31:11 +0000 Subject: More updates for the caps mechanism --- ytstenut-protocol-messages.xsd | 6 + ytstenut-protocol-status.xsd | 3 + ytstenut-protocol.xml | 310 ++++++++++++++++++++++++----------------- 3 files changed, 192 insertions(+), 127 deletions(-) diff --git a/ytstenut-protocol-messages.xsd b/ytstenut-protocol-messages.xsd index d5543ee..e0f7fd4 100644 --- a/ytstenut-protocol-messages.xsd +++ b/ytstenut-protocol-messages.xsd @@ -14,6 +14,12 @@ + + diff --git a/ytstenut-protocol-status.xsd b/ytstenut-protocol-status.xsd index 60e5e91..89712ac 100644 --- a/ytstenut-protocol-status.xsd +++ b/ytstenut-protocol-status.xsd @@ -17,6 +17,9 @@ + diff --git a/ytstenut-protocol.xml b/ytstenut-protocol.xml index 784197f..82fa363 100644 --- a/ytstenut-protocol.xml +++ b/ytstenut-protocol.xml @@ -105,7 +105,7 @@ - 2010 + 2011 Intel Corporation @@ -559,18 +559,6 @@
Link-local Ytstenut protocol - - - tf - Intel - - - - We might be able to piggyback directly on local-xmpp, so this might - go. - - - The link-local Ytstenut protocol allows for automatic connection between Ytstenut clients running on the same LAN. It is derived from the @@ -631,22 +619,22 @@
+
+ Application/Service Identifier + + + Each application/service is identified by a unique identifier. The + identifier is constructed following the D-Bus naming + convention, e.g., + com.meego.BestestFriendApplication. This identifier is used + to identify message and status senders and recipients as described later + in this document. + +
+
Descriptive Application Information - - - tf - Intel - - - This is in keeping with XPMN device management, but AFAIK XPMN is - missing the definition of user-friendly device and service - description. Something along these lines should be added to the XPMN - spec for service description. - - - Ytstenut applications need to provide descriptive information about themselves that can be presented to the user. At the bare minimum, this @@ -654,115 +642,156 @@ - The mechanism for obtaining descriptive application information is XMPP - Entity Capabilities extension; the descriptive information is contained - in a <identity/> element of category - 'client'. Two new types are defined for use with this category: - 'ytstenut-application' and - 'ytstenut-controller', corresponding to task-oriented and - control applications respectively (see ). + The descriptive information is advertised together with the application + capabilities, as described in +
- - The name attribute of the <identity/> - element holds application name, while the xml:lang - attribute identifies the locale used by the name - attribute. As per XMPP Service Discovery extension, the query reply may include multiple - <identity/> elements of the same category and type, - but with different xml:lang attribute. - +
+ Application/Service Capabilities - If the <query/> of the original request has an - explicit xml:lang attribute, the reply contents should be - filtered by that attribute. If the xml:lang attribute of - the <query/> cannot be matched the respondent may - return either a suitable fall-back, or all available translations. + Ytstenut applications/services advertise their Ytstenut capabilities via + XMPP Entity Capabilities protocol, using + urn:ytstenut:capabilities as the value of the + node attribute of the <c/> element. - (For full description of the XML elements, see ). + When the device capabilities are queried, capabilities of each + application/service are represented in the <iq/> + reply using XMPP data form; the form format is best described by an + example: - - Application Information XML example - - - - - - - - ... - - + + + tf + Intel + + + Need to formaly specify a localisation mechanism for the form fields. + + - + + + + + urn:ytstenut:capabilities#org.gnome.Banshee + + + + application + + + + en_GB/Banshee Media Player + fr/Banshee Lecteur de Musique + + + + urn:ytstenut:capabilities:yts-caps-audio + urn:ytstenut:data:jingle:rtp + + +]]> -]]> - - + + Data form fields: -
+ + FORM_TYPE + + + Links the form to the application; the value is constructed by + concatenating an 'urn:ytstenut:capabilies#' prefix + with the application unique identifier (see ), + + + Required. + + + -
- Application Capabilities + + type + - + tf Intel - This is in keeping with XPMN device and service management. + Review whether this distinction is really meaningfull, or whether + 'control' should not be another kind of capability. - - Ytstenut applications must advertise their Ytstenut capabilities via - XMPP Entity Capabilities protocol, using - urn:ytstenut:capabilities as the value of the - node attribute of the <c/> element. - + + The application/service type; either application or + controller. + - - Each individual Ytstenut capability is represented by the - <feature/> element; the var attribute is - constructed by concatenating an 'urn:ytstenut:capabilies:' - prefix and the canonical name of the capability (for standard - capabilities defined in ). - + + Required. + + + - - In addition, Ytstenut applications should also advertise any data - transfer protocols they support as above, using the urns - defined in as the value - of the var attribute. For example, an application - supporting video playback capability and able to stream files via Jingle - RTP would be represented as: - + + name + + + A localised application/service name. + - - - - -]]> + + Required. + + + + + + capabilities + + + + List of application/service capabilites; the values are + constructed by concatenating an + 'urn:ytstenut:capabilies:' prefix and the canonical + name of the capability (for standard capabilities defined in ). + + + The capability list should further include any data transfer + protocols supported, using the urns defined in as additional values. + + + + Required. + + + + + + vendor + + + A localised vendor name. + + + Optional. + + + +
@@ -794,6 +823,17 @@ + + from-service + + + + The ID of the application this status message describes; + required (see ). + + + + capability @@ -856,6 +896,7 @@ + + from-service + + + + The ID of the application that sent this message; + required (see ). + + + + + + to-service + + + + The ID of the application that this message is for; + required (see ). + + + + type @@ -922,22 +985,6 @@ defined by this specification, but custom child elements are allowed. - - - tf - Intel - - - In terms of TP API, I am thinking that the simplest way would be to - provide access to the message XML payload, either in some parsed - form that might be available in Wocky, or, perhaps even the raw XML - (the assumption is that there will be a higher level library sitting - on the top of telepathy-glib/qt that will provide conveniece API for - developers, so this could take care of how to represent this to the - developer. - - -
@@ -1016,6 +1063,8 @@ - XEP-0030 + XEP-0004 Data Forms XMPP Standards Foundation @@ -1857,6 +1906,13 @@ + + D-Bus Specification + + + + + -- cgit v1.2.3