Hi Jose,
> > > Health Device Profile hierarchy
> > > ===============================
> > >
> > > Service org.bluez
> > > Interface org.bluez.HealthAdapter
> > > Object path [variable prefix]/{hci0,hci1,...}
> >
> > so I changed my mind here. Basing this on the local adapter is rather
> > pointless.
> >
> > Lets just do org.bluez.HealthManager on /org/bluez object path. There is
> > no need that the calling application knows anything about the specific
> > adapters in our system. We properly separate them anyway during paring.
> >
> > Only the application that does the initial pairing with a remote health
> > device needs to know which adapter to use. For the actual health
> > application it is pointless since it will be notified about the paired
> > health device initially.
>
> In case we don't use an adapter how can we know were the connections are
> waited. ¿In all the adapters? Remember that this is going to create an SDP
> record and also open l2cap sockets waiting data channels.
so you only need to wait on the adapters that have been paired with a
remote device. However also it is just okay to listen via all adapters.
I don't see a direct need to differentiate this.
> > > Methods:
> > > path CreateApplication(object path, dict config)
> > >
> > > Returns the path of the new created application. The path
> > > parameter is the path of the object with the callbacks to
> > > notify events (see org.bluez.HealthAgent at the end of this
> > > document)
> > > This petition starts an mcap instance and also register a proper
> > > record in the SDP if is needed.
> > >
> > > Dict is defined as bellow:
> > > {
> > >
> > > "end_points" : [{ (optional)
> > >
> > > "role" : ("source" or "sink"), (mandatory)
> > > "specs" :[{ (mandatory)
> > >
> > > "data_type" : uint16, (mandatory)
> > > "description" : string, (optional)
> > >
> > > }]
> > >
> > > }]
> > >
> > > }
> > >
> > > Application will be closed by the call or implicitly when the
> > > programs leaves the bus.
> > >
> > > Possible errors: org.bluez.Error.InvalidArguments
> > >
> > > void ReleaseApplication(path application)
> > >
> > > Closes the HDP application identified by the object path. Also
> > > application will be closed if the process that started it leaves
> > > the bus. If there is a SDP record associated to this application
> > > it will be removed.
> > >
> > > Possible errors: org.bluez.Error.InvalidArguments
> > >
> > > org.bluez.Error.NotFound
> >
> > Since we now make this as part of a generic manager, the method class
> > RegisterApplication and UnregisterApplication are a lot better choice.
> >
> > > array GetRemoteApplications(path application)
> > >
> > > This method will return an array with the paths of all the
> > > remote instances found in remote devices.
> > >
> > > Possible errors: org.bluez.Error.InvalidArguments
> > >
> > > org.bluez.Error.NotFound
> >
> > We don't wanna do that. When you register your application the first
> > callback via the agent should be telling what remote instances are
> > available.
> >
> > This has the advantage that the code flow for the application is
> > simpler. It just has to listen to that update. And if you register your
> > application before pairing with a new device, it will still work. So no
> > extra work to listen for new devices and bootstrapping an existing list.
> >
> > > -------------------------------------------------------------------------
> > > -------
> > >
> > > Service org.bluez
> > > Interface org.bluez.HealthDevice
> > > Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
> >
> > This is not really a health device. As mentioned yesterday, we can have
> > multiple health service per remote device. So we should be using here
> > are org.bluez.HealthService for every SDP record for HDP inside the
> > remote device.
> >
> > So potential object paths are .../hci0/dev_xxxxxxxx/{hdp0,hdp1,...} and
> > so on. This way we clearly map health service and not bother with remote
> > device details that might implement multiple functions.
>
> This object is created on each adapter for refreshing the SDP records. It is
> supposed to search again for HDP records on the device and notify them to the
> proper agents.
That can be done automatically via existing BlueZ D-Bus APIs. I don't
think there is need to have specific functionality.
> > > Methods:
> > > void Refresh()
> > >
> > > This method searches for HDP applications in the remote device
> > > and notifies them to the appropriate agents.
> >
> > I might have called this Update(), but that is a minor detail.
>
> Ok
>
> >
> > > -------------------------------------------------------------------------
> > > -------
> > >
> > > Service org.bluez
> > > Interface org.bluez.HealthDeviceApplication
> > > Object path [variable
> > > prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/hdp_YYYY
> >
> > That is more like the org.bluez.HealthService as mentioned above. So
> > lets combine them. I don't see a need for splitting these.
>
> As I mentioned above, I think next methods and the previous one are different.
> Is a little bit ugly but I think that is necessary to have a way for check
> again the SDP records looking for new remote instances (or applications).
>
> >
> > > Methods:
> > > array GetProperties()
> > >
> > > Gets the information of the remote application published on its
> > > SDP record. The returned data format is as follows:
> > >
> > > {
> > >
> > > "end_points": [
> > >
> > > "mdepid": uint8,
> > > "role" : "source" or "sink" ,
> > > "specs" : [{
> > >
> > > "dtype" : uint16,
> > > "description" : string, (optional)
> > > }]
> > >
> > > ]
> > >
> > > }
> > >
> > > object Connect(path local_application_id)
> > >
> > > Connects the local application with the remote application.
> > >
> > > Only the bus client that created the local session will be able
> > > to create connections using it.
> > >
> > > If the Device is already connected with an other application an
> > > org.bluez.Error.AlreadyConnected error will be received.
> > >
> > > Possible errors: org.bluez.Error.InvalidArguments
> > >
> > > org.bluez.Error.AlreadyConnected
> > > org.bluez.Error.HealthError
> > >
> > > void Disconnect()
> > >
> > > Disconnect from the remote application the state will also be
> > > deleted. And no future reconnections will be possible. For
> > > keeping the state the method Pause of the health link should be
> > > used.
> > >
> > > Possible errors: org.bluez.Error.InvalidArguments
> > >
> > > org.bluez.Error.NotFound
> > > org.bluez.Error.HealthError
> >
> > Do we need Connect() and Disconnect() here. Can we just not create these
> > connections in the background based of a reference counting via the
> > channels?
>
> This functions offer an abstraction to create a mcl and removing it from
> cache. As status is maintained even when the connection is off. So Connect is
> something like start keeping state and Disconnect is like stop keeping state.
I don't see a need here. That can be hidden from the application. I
would make the channel look persistent and not bother with manual
connect of the MCL entity.
> > > boolean Echo(array{byte})
> > >
> > > Sends an echo petition to the remote intance. Returns True if
> > > response matches with the buffer sent. If some error is detected
> > > False value is returned and the associated MCL is closed.
> > >
> > > path OpenDataChannel(byte mdepid, string conf)
> > >
> > > Creates a new data channel with the indicated config to the
> > > remote MCAP Data End Point (MDEP).
> > > The configuration should indicate the channel quality of
> > > service using one of this values "reliable", "streaming", "any".
> > >
> > > Returns the data channel path.
> > >
> > > Possible errors: org.bluez.Error.InvalidArguments
> > >
> > > org.bluez.Error.HealthError
> > >
> > > void ReconnectDataChannel(path data_channel)
> > >
> > > Reconnects a previously created data channel indicated by its
> > > path.
> > >
> > > Possible errors: org.bluez.Error.InvalidArguments
> > >
> > > org.bluez.Error.HealthError
> > > org.bluez.Error.NotFound
> > >
> > > int GetDataChannelFileDescriptor(path data_channel)
> > >
> > > Gets a file descriptor where data can be read or written.
> > >
> > > Possible errors: org.bluez.Error.InvalidArguments
> > >
> > > org.bluez.Error.NotFound
> > > org.bluez.Error.HealthError
> > >
> > > void DeleteDataChannel(path data_channel)
> > >
> > > Deletes a data channel so it will not be available to use.
> > >
> > > Possible errors: org.bluez.Error.InvalidArguments
> > >
> > > org.bluez.Error.NotFound
> > > org.bluez.Error.HealthError
> > >
> > > void DeleteAllDataChannels()
> > >
> > > Deletes all data channels so they will not be available for
> > > future use. Typically this function is called when the
> > > connection with the remote device will be closed permanently.
> > >
> > > Possible errors: org.bluez.Error.HealthError
> >
> > This actually means also Disconnect() to me. So clear the extra work of
> > connect and disconnect can be done in the background and invisible for
> > the user.
>
> It is not just the same. Probably the explanations is not very pointless. This
> is a way for deleting all data channels but keeping the connection active
> (waiting for more channel creation)
That is fine, but way? We can use and idle timeout to keep the
connection around and disconnect it after inactivity. That is a good way
of handling this anyway. And if disconnect, then the other side just
needs to reestablish it again. Happens. I don't want the upper layer to
worry about these details.
> >
> > > dict GetDataChannelStatus()
> > >
> > > Return a dictionary with all the data channels that can be used
> > > to send data right now. The dictionary is formed like follows:
> > >
> > > {
> > >
> > > "reliable": [channel_path_r1, channel_path_r2, ...],
> > > "streaming" : [channel_path_s1, channel_path_s2, ...]
> > >
> > > }
> > >
> > > The fist reliable data channel will always be the first data
> > > channel in reliable array.
> > >
> > > 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 DeviceApplicationDiscovered(object path)
> > >
> > > This method is called when a device containing an hdp
> > > application is connected. The object path is the application
> > > path. The method will be called one time for each
> > > application.
> >
> > I think this should be ServiceDiscovered and map to a HealthService.
>
> Ok
>
> >
> > > void DeviceConnected(object path)
> > >
> > > This method is called whenever a new connection has been
> > > established over the control channel of the current HDP
> > > application. The object path paremeter contains the object path
> > > of the connected HealthDevice.
> >
> > Don't see a useful need for this. I don't want to expose HealthDevice
> > details anyway.
>
> What this tries to mean is that this HealthService has connected with the
> local Application so the application can open data channels with it now.
And why does it care? It only cares when a channel has been created.
What is the benefit about telling about a physical link that has no
users yet.
>
> >
> > > void DevicePaused(object path)
> > >
> > > This method is called when a MCL is closed. Future reconnections
> > > will be notified using the DeviceRestarted callback.
> > > All data channels associated to this device will be closed and
> > > a reconnection will be needed before using them again.
> > >
> > > void DeviceResumed(object path)
> > >
> > > This method is called whenever a MCL is reconnected. All data
> > > channels associated are still closed but they will be able to be
> > > reconnected skipping the configuration process.
> > >
> > > void DeviceDisconnected(object path)
> > >
> > > This method is called when a remote device is disconnected or
> > > removed from MCAP cache. Any future reconnections will fail.
> > > Also all data channels associated to this device will be closed.
> >
> > Why bother with this. We can do this on channel level.
>
> The problem is that in some cases (when the remote is not publishing a record)
> it is not possible to open data channels nor reconnecting the mcl so it is not
> possible to make this automatically. The application should be concerned about
> this issues to avoid this kind of operation in this cases.
I can follow the reason. We can figure this out intelligent for the
application. If we can't then neither will the application.
>
> >
> > > void CreatedDataChannel(object path, path data_channel, string conf)
> > >
> > > This method is called when a new data channel is created.
> > >
> > > The path contains the object path of the HealthDeviceApplication
> > > where the new connection is created, the data_channel is the
> > > path for identify the data channel and conf is the quality of
> > > service of the data channel ("reliable" or "streaming").
> >
> > DataChannelCreated please.
> >
> > > void DataChannelReconnected(object path, path data_channel, string
> conf)
> > >
> > > This method is called when a closed data channel is reconnected
> > > by the remote device.
> > >
> > > Conf will be "reliable" or "streaming".
> > >
> > > TThe path contains the object path of the
> > > HealthDeviceApplication where the new connection is reconnected,
> > > the data_channel is the path for identify the data channel and
> > > conf is the quality of service of the data channel ("reliable"
> > > or "streaming").
> > >
> > > void DeletedDataChannel(object path, path data_channel)
> > >
> > > This method is called when a data channel is deleted.
> > >
> > > After this call the data channel path will not be valid and can
> > > be reused for future creation of data channels.
> >
> > DataChannelRemoved. We always map create with remove.
> >
> > > void DeletedAllDataChannels(object path)
> > >
> > > This method is called when all data channels are deleted.
> > >
> > > The path contains the object path of the HealthDeviceApplication
> > > where the data channels are deleted.
> >
> > That is pointless. You will get separate callbacks for each channel
> > anyway.
>
> We tried to avoid calling may times to the same callback when a delete all
> operation is done, but of course it is not necessary.
I would normally agree, but about how many channels are we talking here.
5, 10 or 200. Since I assume this is mostly 2-3 channels sending it
multiple times on cleanup just makes the code flow inside the
application a lot simpler. That is what we want. The extra payload on
the D-Bus can be neglected her in favor of a simpler application work
flow.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
