Changes in HDP API

Changes in HDP API

[Jose Antonio Santos Cadenas]

This patch makes some changes in the HDP API based in the conversation that I
had yesterday with Luiz and Elvis.

I still have a doubt about the notification of devices in the agent. Luiz
commented that with this API the Agent and the Application could not be in
different processes, is this a problem?

An other open issue is: if we notify when a device is discovered and suitable
for connect with an application and when a devices is removed (or becomes not
suitable for connect). I think that we already need something like the patch
that we start discussing yesterday, something that can be called by the user
in order to force a new service discovery and notifies the driver that will
notify the agent. Of course we can avoid this not notifying the suitable
devices and just letting to try the connection against all the devices (if
there is no matching service it will fail). What do you think?

Regards.

Jose.

[PATCH] Changes in HDP API.

[Jose Antonio Santos Cadenas]

Now the connection is made directly to a device and bluetoothd daemon
guess the PSM connection and the MDEPID based on the data get from the
SDP record.
---
 doc/health-api.txt |   33 +++++++++++++--------------------
 1 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/doc/health-api.txt b/doc/health-api.txt
index f469df3..aa462bd 100644
--- a/doc/health-api.txt
+++ b/doc/health-api.txt
@@ -47,12 +47,12 @@ Methods:
 --------------------------------------------------------------------------------
 
 Service		org.bluez
-Interface	org.bluez.HealthApplication
-Object path	[variable prefix]/health_app_ZZZZ
+Interface	org.bluez.HealthDevice
+Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
 
 Methods:
 
-	void Echo(object service)
+	void Echo(object application)
 
 		Sends an echo petition to the remote service. Returns True if
 		response matches with the buffer sent. If some error is detected
@@ -61,7 +61,7 @@ Methods:
 		Possible errors: org.bluez.Error.InvalidArguments
 				org.bluez.Error.OutOfRange
 
-	object CreateChannel(object service, string type)
+	object CreateChannel(object application, string type)
 
 		Creates a new data channel with the indicated config to the
 		remote Service.
@@ -74,18 +74,12 @@ Methods:
 		Possible errors: org.bluez.Error.InvalidArguments
 				org.bluez.Error.HealthError
 
-	void DestroyChannel(object channel)
+	void DestroyChannel(object application)
 
 		Destroys the data channel object.
 
 		Possible errors: org.bluez.Error.InvalidArguments
-				orb.bluez.Error.NotFound
-
---------------------------------------------------------------------------------
-
-Service		org.bluez
-Interface	org.bluez.HealthService
-Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/hdp_YYYY
+				org.bluez.Error.NotFound
 
 --------------------------------------------------------------------------------
 
@@ -142,18 +136,17 @@ Methods:
 		to unregister the agent, because when this method gets called it
 		has already been unregistered.
 
-	void ServiceDiscovered(object service)
+	void DeviceDiscovered(object device)
 
 		This method is called when a device containing an HDP
-		application is paired or when the method Update of the
-		HealthManager is called and new HealthServices are discovered.
-		The method will be called once for each HealthService.
+		application is paired and is suitable for connect with the
+		application that registered this agent.
 
-	void ServiceRemoved(object service)
+	void DeviceRemoved(object device)
 
-		This is called if during an Update some HealthServices
-		have disappeared. The method is called once for each removed
-		HealthService.
+		This method is called if a device that was suitable for
+		connecting with the application becomes not suitable for
+		connecting with the application.
 
 	void ChannelConnected(object channel)
 
-- 
1.7.0.4

Re: Changes in HDP API

[Luiz Augusto von Dentz]

Hi,

On Wed, Aug 4, 2010 at 10:49 AM, Jose Antonio Santos Cadenas
<santoscadenas@gmail.com> wrote:
> This patch makes some changes in the HDP API based in the conversation that I
> had yesterday with Luiz and Elvis.
>
> I still have a doubt about the notification of devices in the agent. Luiz
> commented that with this API the Agent and the Application could not be in
> different processes, is this a problem?
>
> An other open issue is: if we notify when a device is discovered and suitable
> for connect with an application and when a devices is removed (or becomes not
> suitable for connect). I think that we already need something like the patch
> that we start discussing yesterday, something that can be called by the user
> in order to force a new service discovery and notifies the driver that will
> notify the agent. Of course we can avoid this not notifying the suitable
> devices and just letting to try the connection against all the devices (if
> there is no matching service it will fail). What do you think?
>
> Regards.

Lets say you want the pairing agent to connect right after pairing or
directly via applet, these applications has zero knowledge of what
endpoints the devices has, that why I suggest something simpler, so we
might only need e.g. HealthDevice which the applet can say, please
connect to this device so it calls e.g. HealthDevice.Connect(), this
basically will start a discovery of the health endpoints on
bluetoothd, then it matches with local endpoints (HealthApplication),
create the channels which are informed to the HealthAgent which can
then acquire the file descriptor.

This has 2 main advantages:

1.  Anyone can request to connect not only applications which holds
local endpoints
2.  There is no need to fetch the services, discovery will take place
every time the application attempt to connect.

-- 
Luiz Augusto von Dentz
Computer Engineer

Re: Changes in HDP API

[José Antonio Santos Cadenas]

Hello,

El Wednesday 04 August 2010 15:09:49 Luiz Augusto von Dentz escribió:
> Hi,
> 
> On Wed, Aug 4, 2010 at 10:49 AM, Jose Antonio Santos Cadenas
> 
> <santoscadenas@gmail.com> wrote:
> > This patch makes some changes in the HDP API based in the conversation
> > that I had yesterday with Luiz and Elvis.
> > 
> > I still have a doubt about the notification of devices in the agent. Luiz
> > commented that with this API the Agent and the Application could not be
> > in different processes, is this a problem?
> > 
> > An other open issue is: if we notify when a device is discovered and
> > suitable for connect with an application and when a devices is removed
> > (or becomes not suitable for connect). I think that we already need
> > something like the patch that we start discussing yesterday, something
> > that can be called by the user in order to force a new service discovery
> > and notifies the driver that will notify the agent. Of course we can
> > avoid this not notifying the suitable devices and just letting to try
> > the connection against all the devices (if there is no matching service
> > it will fail). What do you think?
> > 
> > Regards.
> 
> Lets say you want the pairing agent to connect right after pairing or
> directly via applet, these applications has zero knowledge of what
> endpoints the devices has, that why I suggest something simpler, so we
> might only need e.g. HealthDevice which the applet can say, please
> connect to this device so it calls e.g. HealthDevice.Connect(), this
> basically will start a discovery of the health endpoints on
> bluetoothd, then it matches with local endpoints (HealthApplication),
> create the channels which are informed to the HealthAgent which can
> then acquire the file descriptor.

I like this approach more than the previous one. But I still have one 
question. I write it further down.

> 
> This has 2 main advantages:
> 
> 1.  Anyone can request to connect not only applications which holds
> local endpoints

How can you guess the remote end point to connect to if you don't have a local 
end point?

> 2.  There is no need to fetch the services, discovery will take place
> every time the application attempt to connect.

I agree with this one. Less discovery implies less traffic and less battery 
consumption and bandwidth.

Regards.

Re: Changes in HDP API

[Luiz Augusto von Dentz]

Hi,

On Wed, Aug 4, 2010 at 4:54 PM, José Antonio Santos Cadenas
<santoscadenas@gmail.com> wrote:
>> This has 2 main advantages:
>>
>> 1.  Anyone can request to connect not only applications which holds
>> local endpoints
>
> How can you guess the remote end point to connect to if you don't have a local
> end point?

There is no endpoints involved in this case, bluetooth applet/agent
has knowledge only of the device so bluetoothd will need to figure out
all the matching endpoint and make sure local endpoint get notified
about the available channels, so responding your question there is
nothing to guess it all about matching the endpoints if there is no
match it just fails after the discover as simple as that.

At least that is the idea around connect/disconnect in gnome-bluetooth
and N900 bluetooth application does have a similar design.

-- 
Luiz Augusto von Dentz
Computer Engineer

Re: Changes in HDP API

[José Antonio Santos Cadenas]

Hi,

El Wednesday 04 August 2010 18:45:50 Luiz Augusto von Dentz escribió:
> Hi,
> 
> On Wed, Aug 4, 2010 at 4:54 PM, José Antonio Santos Cadenas
> 
> <santoscadenas@gmail.com> wrote:
> >> This has 2 main advantages:
> >> 
> >> 1.  Anyone can request to connect not only applications which holds
> >> local endpoints
> > 
> > How can you guess the remote end point to connect to if you don't have a
> > local end point?
> 
> There is no endpoints involved in this case, bluetooth applet/agent
> has knowledge only of the device so bluetoothd will need to figure out
> all the matching endpoint and make sure local endpoint get notified
> about the available channels, so responding your question there is
> nothing to guess it all about matching the endpoints if there is no
> match it just fails after the discover as simple as that.

Sorry but I don't understand the answer. I think that the daemon needs to 
guess the remote end point to connect to when the user performs a connection 
of a data channel to a device (I mean the mdepid where the data channel will 
be connected). In HDP each data channel can be configured in a specific way 
(reliable or streaming) and is connected for an specific usage (that's the 
data type parameter in the SDP record) so you have to specify this during the 
connection of the channel.

An other thing to solve is the way that the data channel deletion is notified 
if there is no associated agent, I mean, if you just do a Connect without 
registering an agent first. This kind of events are supposed to be received by 
the agent. An other special issue of HDP, data channels can be open or closed 
but they are still active because reconnections are possible and this implies 
no disconnection for the application layer.

> 
> At least that is the idea around connect/disconnect in gnome-bluetooth
> and N900 bluetooth application does have a similar design.

I don't know how this is exactly working (I'll have a deeper look), but I 
guess that only one agent is allowed. I think that will be great to have 
multiple agents in HDP because more than one application can be using HDP at 
the same time. I don't know if with only one agent this can be solved.

Regards

Jose.

Re: Changes in HDP API

[Elvis Pfützenreuter]

On 04/08/2010, at 04:49, Jose Antonio Santos Cadenas wrote:

> This patch makes some changes in the HDP API based in the conversation that I
> had yesterday with Luiz and Elvis.
> 
> I still have a doubt about the notification of devices in the agent. Luiz
> commented that with this API the Agent and the Application could not be in
> different processes, is this a problem?

Is not a problem and IMHO it does not make sense at all. The Agent in HDP API context is as a mere vehicle for callbacks, because signals are seen by every process while the nature of health devices demands some privacy/secrecy (I have a faint memory about privacy being a general requirement for IEEE protocol as well as Continua certification.)

The agent is always coupled with an application. The most typical usage of BlueZ HDP is as sink role, which means the application creates the application, which publishes the role via SDP, and sits idle until some source connects, which is notified via the agent.

Re: Changes in HDP API

[José Antonio Santos Cadenas]

El Wednesday 04 August 2010 20:22:29 Elvis Pfützenreuter escribió:
> On 04/08/2010, at 04:49, Jose Antonio Santos Cadenas wrote:
> > This patch makes some changes in the HDP API based in the conversation
> > that I had yesterday with Luiz and Elvis.
> > 
> > I still have a doubt about the notification of devices in the agent. Luiz
> > commented that with this API the Agent and the Application could not be
> > in different processes, is this a problem?
> 
> Is not a problem and IMHO it does not make sense at all. The Agent in HDP
> API context is as a mere vehicle for callbacks, because signals are seen
> by every process while the nature of health devices demands some
> privacy/secrecy (I have a faint memory about privacy being a general
> requirement for IEEE protocol as well as Continua certification.)

I've been thinking about this issue and I'm changing my opinion about this a 
little bit. I will expose my "new" view and later today I will send a new API 
proposal if you think this approach is OK.

In fact the privacy issue should concern to the data that is being transmitted 
over the data channel, not the creation and destruction of the data channel. 
If we start from that point. Sending new channel events as signals will not be 
a privacy problem if we protect the data channel itself.

The DataChannel object (as is defined in the current API) could be protected 
and only reply to method calls from the process owner of the application that 
waited for this data channel (if it was opened by the remote side) or from the 
creator of the data channel (if it was opened by the local side). This way 
only this process will be able to get the file descriptor (what means get 
access to the data) and to manage the connection closing, reconnecting or 
deleting the data channel. So in this way the privacy of the data is 
guaranteed.

An other thing to take into account is that all the application will be 
bothered with signals of data channel creation an deletion even when they 
could not use them. But I thing that this is not too much extra load because 
in a typical scenario only one or two application will be interested in health 
data channels.

> 
> The agent is always coupled with an application. The most typical usage of
> BlueZ HDP is as sink role, which means the application creates the
> application, which publishes the role via SDP, and sits idle until some
> source connects, which is notified via the agent.


Regards.

[PATCH] Changes in HDP API.

[Jose Antonio Santos Cadenas]

Now the connection is made directly to a device and bluetoothd daemon
guess the PSM connection and the MDEPID based on the data get from the
SDP record.
---
 doc/health-api.txt |  105 ++++++++++++++++++++--------------------------------
 1 files changed, 40 insertions(+), 65 deletions(-)

diff --git a/doc/health-api.txt b/doc/health-api.txt
index f469df3..89df8bd 100644
--- a/doc/health-api.txt
+++ b/doc/health-api.txt
@@ -14,12 +14,9 @@ Object path	/org/bluez/
 
 Methods:
 
-	object	CreateApplication(dict config, object agent)
+	object	CreateApplication(dict config)
 
-		Returns the path of the new registered application. The agent
-		parameter is the path of the object with the callbacks to
-		notify events (see org.bluez.HealthAgent at the end
-		of this document).
+		Returns the path of the new registered application.
 
 		Dict is defined as bellow:
 		{
@@ -39,32 +36,33 @@ Methods:
 
 		Closes the HDP application identified by the object path. Also
 		application will be closed if the process that started it leaves
-		the bus.
+		the bus. Only the creator of the application will be able to
+		destroy it.
 
 		Possible errors: org.bluez.Error.InvalidArguments
 				org.bluez.Error.NotFound
+				org.bluez.Error.NotAllowed
 
 --------------------------------------------------------------------------------
 
 Service		org.bluez
-Interface	org.bluez.HealthApplication
-Object path	[variable prefix]/health_app_ZZZZ
+Interface	org.bluez.HealthDevice
+Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
 
 Methods:
 
-	void Echo(object service)
+	Boolean Echo()
 
 		Sends an echo petition to the remote service. Returns True if
 		response matches with the buffer sent. If some error is detected
-		False value is returned and the associated MCL is closed.
+		False value is returned.
 
 		Possible errors: org.bluez.Error.InvalidArguments
 				org.bluez.Error.OutOfRange
 
-	object CreateChannel(object service, string type)
+	object CreateChannel(object application, string configuration)
 
-		Creates a new data channel with the indicated config to the
-		remote Service.
+		Creates a new data channel.
 		The configuration should indicate the channel quality of
 		service using one of this values "Reliable", "Streaming", "Any".
 
@@ -76,16 +74,27 @@ Methods:
 
 	void DestroyChannel(object channel)
 
-		Destroys the data channel object.
+		Destroys the data channel object. Only the creator of the
+		channel or the creator of the HealtApplication that received the
+		data channel will be able to destroy it
 
 		Possible errors: org.bluez.Error.InvalidArguments
-				orb.bluez.Error.NotFound
+				org.bluez.Error.NotFound
+				org.bluez.Error.NotAllowed
 
---------------------------------------------------------------------------------
+Signals:
 
-Service		org.bluez
-Interface	org.bluez.HealthService
-Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/hdp_YYYY
+	void ChannelConnected(object channel)
+
+		This signal is launched when a new data channel is created or
+		when a known data channel is reconnected.
+
+	void ChannelDeleted(object channel)
+
+		This signal is launched when a data channel is deleted.
+
+		After this signal the data channel path will not be valid and
+		its path can be reused for future data channels.
 
 --------------------------------------------------------------------------------
 
@@ -94,6 +103,9 @@ Interface	org.bluez.HealthChannel
 Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/
 							hdp_YYYY/channel_ZZ
 
+Only the process that created the data channel or the creator of the
+HealthApplication that received it will be able to call this methods.
+
 Methods:
 
 	dict GetProperties()
@@ -101,17 +113,23 @@ Methods:
 		Returns all properties for the interface. See the properties
 		section for available properties.
 
+		Posible errors: org.bluez.Error.NotAllowed
+
 	fd Acquire()
 
 		Returns the file descriptor for this data channel. If the data
 		channel is not connected it will also reconnect.
 
 		Possible errors: org.bluez.Error.NotConnected
+				org.bluez.Error.NotAllowed
 
 	void Release()
 
 		Releases the fd. Application should also need to close() it.
 
+		Possible errors: org.bluez.Error.NotAcquired
+				org.bluez.Error.NotAllowed
+
 Properties:
 
 	string Type (read only)
@@ -119,50 +137,7 @@ Properties:
 		The quality of service of the data channel. ("Reliable" or
 		"Streaming")
 
-	object Service (read only)
-
-		Identifies the Remote Service that is connected with. Maps with
-		a HealthService object.
-
-HealthAgent hierarchy
-=====================
-
-(this object is implemented by the HDP user in order to receive notifications)
-
-Service		unique name
-Interface	org.bluez.HealthAgent
-Object path	freely definable
-
-Methods:
-
-	void Release()
-
-		This method gets called when the service daemon unregisters the
-		agent. An agent can use it to do cleanup tasks. There is no need
-		to unregister the agent, because when this method gets called it
-		has already been unregistered.
-
-	void ServiceDiscovered(object service)
-
-		This method is called when a device containing an HDP
-		application is paired or when the method Update of the
-		HealthManager is called and new HealthServices are discovered.
-		The method will be called once for each HealthService.
-
-	void ServiceRemoved(object service)
-
-		This is called if during an Update some HealthServices
-		have disappeared. The method is called once for each removed
-		HealthService.
-
-	void ChannelConnected(object channel)
-
-		This method is called when a new data channel is created or when
-		a known data channel is reconnected.
-
-	void ChannelDeleted(object channel)
-
-		This method is called when a data channel is deleted.
+	object Device (read only)
 
-		After this call the data channel path will not be valid and can
-		be reused for future creation of data channels.
+		Identifies the Remote Device that is connected with. Maps with
+		a HealthDevice object.
-- 
1.7.0.4

Re: [PATCH] Changes in HDP API.

[Santiago Carot-Nemesio]

On 08/05/10 15:49, Jose Antonio Santos Cadenas wrote:
> Now the connection is made directly to a device and bluetoothd daemon
> guess the PSM connection and the MDEPID based on the data get from the
> SDP record.
> ---
>   doc/health-api.txt |  105 ++++++++++++++++++++--------------------------------
>   1 files changed, 40 insertions(+), 65 deletions(-)
>
> diff --git a/doc/health-api.txt b/doc/health-api.txt
> index f469df3..89df8bd 100644
> --- a/doc/health-api.txt
> +++ b/doc/health-api.txt
> @@ -14,12 +14,9 @@ Object path	/org/bluez/
>
>   Methods:
>
> -	object	CreateApplication(dict config, object agent)
> +	object	CreateApplication(dict config)
>
> -		Returns the path of the new registered application. The agent
> -		parameter is the path of the object with the callbacks to
> -		notify events (see org.bluez.HealthAgent at the end
> -		of this document).
> +		Returns the path of the new registered application.
>
>   		Dict is defined as bellow:
>   		{
> @@ -39,32 +36,33 @@ Methods:
>
>   		Closes the HDP application identified by the object path. Also
>   		application will be closed if the process that started it leaves
> -		the bus.
> +		the bus. Only the creator of the application will be able to
> +		destroy it.
>
>   		Possible errors: org.bluez.Error.InvalidArguments
>   				org.bluez.Error.NotFound
> +				org.bluez.Error.NotAllowed
>
>   --------------------------------------------------------------------------------
>
>   Service		org.bluez
> -Interface	org.bluez.HealthApplication
> -Object path	[variable prefix]/health_app_ZZZZ
> +Interface	org.bluez.HealthDevice
> +Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
>
>   Methods:
>
> -	void Echo(object service)
> +	Boolean Echo()
>
>   		Sends an echo petition to the remote service. Returns True if
>   		response matches with the buffer sent. If some error is detected
> -		False value is returned and the associated MCL is closed.
> +		False value is returned.
>
>   		Possible errors: org.bluez.Error.InvalidArguments
>   				org.bluez.Error.OutOfRange
>
> -	object CreateChannel(object service, string type)
> +	object CreateChannel(object application, string configuration)
>
> -		Creates a new data channel with the indicated config to the
> -		remote Service.
> +		Creates a new data channel.
>   		The configuration should indicate the channel quality of
>   		service using one of this values "Reliable", "Streaming", "Any".
>
> @@ -76,16 +74,27 @@ Methods:
>
>   	void DestroyChannel(object channel)
>
> -		Destroys the data channel object.
> +		Destroys the data channel object. Only the creator of the
> +		channel or the creator of the HealtApplication that received the
> +		data channel will be able to destroy it
>
>   		Possible errors: org.bluez.Error.InvalidArguments
> -				orb.bluez.Error.NotFound
> +				org.bluez.Error.NotFound
> +				org.bluez.Error.NotAllowed
>
> ---------------------------------------------------------------------------------
> +Signals:
>
> -Service		org.bluez
> -Interface	org.bluez.HealthService
> -Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/hdp_YYYY
> +	void ChannelConnected(object channel)
> +
> +		This signal is launched when a new data channel is created or
> +		when a known data channel is reconnected.
> +
> +	void ChannelDeleted(object channel)
> +
> +		This signal is launched when a data channel is deleted.
> +
> +		After this signal the data channel path will not be valid and
> +		its path can be reused for future data channels.
>
>   --------------------------------------------------------------------------------
>
> @@ -94,6 +103,9 @@ Interface	org.bluez.HealthChannel
>   Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/
>   							hdp_YYYY/channel_ZZ
>
> +Only the process that created the data channel or the creator of the
> +HealthApplication that received it will be able to call this methods.
> +
>   Methods:
>
>   	dict GetProperties()
> @@ -101,17 +113,23 @@ Methods:
>   		Returns all properties for the interface. See the properties
>   		section for available properties.
>
> +		Posible errors: org.bluez.Error.NotAllowed
> +
>   	fd Acquire()
>
>   		Returns the file descriptor for this data channel. If the data
>   		channel is not connected it will also reconnect.
>
>   		Possible errors: org.bluez.Error.NotConnected
> +				org.bluez.Error.NotAllowed
>
>   	void Release()
>
>   		Releases the fd. Application should also need to close() it.
>
> +		Possible errors: org.bluez.Error.NotAcquired
> +				org.bluez.Error.NotAllowed
> +
>   Properties:
>
>   	string Type (read only)
> @@ -119,50 +137,7 @@ Properties:
>   		The quality of service of the data channel. ("Reliable" or
>   		"Streaming")

In HDP specification there is a special mention for first data channel 
opened that it shall be used for sending specific protocol data. Using 
this API it is impossible diferentiate it from another reliable data 
channels when it changes after a MCL reconnection. For applications 
using HDP is mandatory sending this kind of traffic through the first 
reliable data channel.

I suggest use an special Type for it in addition to "Reliable" and 
"Streaming" such as "Main".

Due that main data channel can change after a MCL reconnection, we need 
notify it to applications. We can expose a new signal similar to hfp-api 
to announce property changes, for example something like this:

+Signals	PropertyChanged(string new_value)
+
+		This signal indicates a property changed value.

Comments are welcome.
Regards.

Re: [PATCH] Changes in HDP API.

[José Antonio Santos Cadenas]

Hi all,

El Thursday 05 August 2010 15:49:43 Jose Antonio Santos Cadenas escribió:
> Now the connection is made directly to a device and bluetoothd daemon
> guess the PSM connection and the MDEPID based on the data get from the
> SDP record.
> ---
>  doc/health-api.txt |  105
> ++++++++++++++++++++-------------------------------- 1 files changed, 40
> insertions(+), 65 deletions(-)
> 
> diff --git a/doc/health-api.txt b/doc/health-api.txt
> index f469df3..89df8bd 100644
> --- a/doc/health-api.txt
> +++ b/doc/health-api.txt
> @@ -14,12 +14,9 @@ Object path	/org/bluez/
> 
>  Methods:
> 
> -	object	CreateApplication(dict config, object agent)
> +	object	CreateApplication(dict config)
> 
> -		Returns the path of the new registered application. The agent
> -		parameter is the path of the object with the callbacks to
> -		notify events (see org.bluez.HealthAgent at the end
> -		of this document).
> +		Returns the path of the new registered application.
> 
>  		Dict is defined as bellow:
>  		{
> @@ -39,32 +36,33 @@ Methods:
> 
>  		Closes the HDP application identified by the object path. Also
>  		application will be closed if the process that started it leaves
> -		the bus.
> +		the bus. Only the creator of the application will be able to
> +		destroy it.
> 
>  		Possible errors: org.bluez.Error.InvalidArguments
>  				org.bluez.Error.NotFound
> +				org.bluez.Error.NotAllowed
> 
>  --------------------------------------------------------------------------
> ------
> 
>  Service		org.bluez
> -Interface	org.bluez.HealthApplication
> -Object path	[variable prefix]/health_app_ZZZZ
> +Interface	org.bluez.HealthDevice
> +Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
> 
>  Methods:
> 
> -	void Echo(object service)
> +	Boolean Echo()
> 
>  		Sends an echo petition to the remote service. Returns True if
>  		response matches with the buffer sent. If some error is detected
> -		False value is returned and the associated MCL is closed.
> +		False value is returned.
> 
>  		Possible errors: org.bluez.Error.InvalidArguments
>  				org.bluez.Error.OutOfRange
> 
> -	object CreateChannel(object service, string type)
> +	object CreateChannel(object application, string configuration)
> 
> -		Creates a new data channel with the indicated config to the
> -		remote Service.
> +		Creates a new data channel.
>  		The configuration should indicate the channel quality of
>  		service using one of this values "Reliable", "Streaming", "Any".
> 
> @@ -76,16 +74,27 @@ Methods:
> 
>  	void DestroyChannel(object channel)
> 
> -		Destroys the data channel object.
> +		Destroys the data channel object. Only the creator of the
> +		channel or the creator of the HealtApplication that received the
> +		data channel will be able to destroy it
> 
>  		Possible errors: org.bluez.Error.InvalidArguments
> -				orb.bluez.Error.NotFound
> +				org.bluez.Error.NotFound
> +				org.bluez.Error.NotAllowed
> 
> ---------------------------------------------------------------------------
> ------ +Signals:
> 
> -Service		org.bluez
> -Interface	org.bluez.HealthService
> -Object path	[variable
> prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/hdp_YYYY +	void
> ChannelConnected(object channel)
> +
> +		This signal is launched when a new data channel is created or
> +		when a known data channel is reconnected.
> +
> +	void ChannelDeleted(object channel)
> +
> +		This signal is launched when a data channel is deleted.
> +
> +		After this signal the data channel path will not be valid and
> +		its path can be reused for future data channels.
> 
>  --------------------------------------------------------------------------
> ------
> 
> @@ -94,6 +103,9 @@ Interface	org.bluez.HealthChannel
>  Object path	[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/
>  							hdp_YYYY/channel_ZZ
> 
> +Only the process that created the data channel or the creator of the
> +HealthApplication that received it will be able to call this methods.
> +
>  Methods:
> 
>  	dict GetProperties()
> @@ -101,17 +113,23 @@ Methods:
>  		Returns all properties for the interface. See the properties
>  		section for available properties.
> 
> +		Posible errors: org.bluez.Error.NotAllowed
> +
>  	fd Acquire()
> 
>  		Returns the file descriptor for this data channel. If the data
>  		channel is not connected it will also reconnect.
> 
>  		Possible errors: org.bluez.Error.NotConnected
> +				org.bluez.Error.NotAllowed
> 
>  	void Release()
> 
>  		Releases the fd. Application should also need to close() it.
> 
> +		Possible errors: org.bluez.Error.NotAcquired
> +				org.bluez.Error.NotAllowed
> +
>  Properties:
> 
>  	string Type (read only)
> @@ -119,50 +137,7 @@ Properties:
>  		The quality of service of the data channel. ("Reliable" or
>  		"Streaming")
> 
> -	object Service (read only)
> -
> -		Identifies the Remote Service that is connected with. Maps with
> -		a HealthService object.
> -
> -HealthAgent hierarchy
> -=====================
> -
> -(this object is implemented by the HDP user in order to receive
> notifications) -
> -Service		unique name
> -Interface	org.bluez.HealthAgent
> -Object path	freely definable
> -
> -Methods:
> -
> -	void Release()
> -
> -		This method gets called when the service daemon unregisters the
> -		agent. An agent can use it to do cleanup tasks. There is no need
> -		to unregister the agent, because when this method gets called it
> -		has already been unregistered.
> -
> -	void ServiceDiscovered(object service)
> -
> -		This method is called when a device containing an HDP
> -		application is paired or when the method Update of the
> -		HealthManager is called and new HealthServices are discovered.
> -		The method will be called once for each HealthService.
> -
> -	void ServiceRemoved(object service)
> -
> -		This is called if during an Update some HealthServices
> -		have disappeared. The method is called once for each removed
> -		HealthService.
> -
> -	void ChannelConnected(object channel)
> -
> -		This method is called when a new data channel is created or when
> -		a known data channel is reconnected.
> -
> -	void ChannelDeleted(object channel)
> -
> -		This method is called when a data channel is deleted.
> +	object Device (read only)
> 
> -		After this call the data channel path will not be valid and can
> -		be reused for future creation of data channels.
> +		Identifies the Remote Device that is connected with. Maps with
> +		a HealthDevice object.


Any more comments about this? Are there any extra things to talk about? It 
will be great to fix this issues so we can continue developing the plugin.

Thanks.

Jose