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.
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
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.
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.
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
>
> <[email protected]> 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.
Hi,
On Wed, Aug 4, 2010 at 4:54 PM, Jos? Antonio Santos Cadenas
<[email protected]> 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
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
>
> <[email protected]> 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.
Hi,
On Wed, Aug 4, 2010 at 10:49 AM, Jose Antonio Santos Cadenas
<[email protected]> 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
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