Re: [PATCH] Initial draft of Application registration API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Luiz,

On Fri, Dec 10, 2010 at 8:31 AM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi,
>
> On Fri, Dec 10, 2010 at 6:13 AM, Claudio Takahasi
> <claudio.takahasi@xxxxxxxxxxxxx> wrote:
>> Âdoc/attribute-api.txt | Â 44 +++++++++++++++++++++++++++++++++++++++++++-
>> Â1 files changed, 43 insertions(+), 1 deletions(-)
>>
>> diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
>> index 23808e6..ab62313 100644
>> --- a/doc/attribute-api.txt
>> +++ b/doc/attribute-api.txt
>> @@ -23,7 +23,6 @@ fully transparent and a differentiation becomes unimportant in the future.
>> ÂA service consists of some generic service information and a set of
>> Âcharacteristics. All characteristic are presented as object path as well.
>>
>> -
>> ÂLocal Service hierarchy
>> Â=======================
>>
>> @@ -37,6 +36,35 @@ Methods
>> ÂProperties
>>
>>
>> +Adapter Application Attribute hierarchy
>> +=======================================
>> +
>> +Service        Âorg.bluez
>> +Interface   Âorg.bluez.Attrib
>> +Object path  Â[variable prefix]/{hci0,hci1,...}
>> +
>> +Methods        Âvoid RegisterApplication(array{string} uuids, dict settings)
>> +
>> + Â Â Â Â Â Â Â Â Â Â Â Method to allow applications to control automatic
>> + Â Â Â Â Â Â Â Â Â Â Â connections to known devices.
>> +
>> + Â Â Â Â Â Â Â Â Â Â Â "settings" dictionary defines the wanted application
>> + Â Â Â Â Â Â Â Â Â Â Â connection parameters. Defined values:
>> + Â Â Â Â Â Â Â Â Â Â Â - Latency: low, medium and high
>> + Â Â Â Â Â Â Â Â Â Â Â - BandWidth: TBD
>> + Â Â Â Â Â Â Â Â Â Â Â - AutoConnect: boolean
>> +
>> + Â Â Â Â Â Â Â Â Â Â Â Latency parameter controls the scan and connect
>> + Â Â Â Â Â Â Â Â Â Â Â interval. AutoConnect parameter controls automatic
>> + Â Â Â Â Â Â Â Â Â Â Â connections if a bonded device emits a connectable
>> + Â Â Â Â Â Â Â Â Â Â Â advertising report.
>> +
>> + Â Â Â Â Â Â Â void UnregisterApplication(array{string} uuids)
>> +
>> + Â Â Â Â Â Â Â Â Â Â Â Unregister a previously registered application.
>> + Â Â Â Â Â Â Â Â Â Â Â Remotes are automatically disconnected if no more
>> + Â Â Â Â Â Â Â Â Â Â Â applications are interested in the given services.
>> +
>> ÂDevice Service hierarchy
>> Â========================
>>
>> @@ -154,3 +182,17 @@ Object path    Âfreely definable
>> ÂMethods        Âvoid ValueChanged(object characteristic, array{byte})
>>
>> Â Â Â Â Â Â Â Â Â Â Â ÂNew raw value of the Characteristic Value attribute.
>> +
>> +Adapter Application Agent hierarchy
>> +====================================
>> +
>> +Service        Âunique name
>> +Interface   Âorg.bluez.Application
>> +Object path  Âfreely definable
>> +
>> +Methods        Âvoid Connected(object device, array{object} services)
>> +
>> + Â Â Â Â Â Â Â Â Â Â Â Indication that a given remote device was found
>> + Â Â Â Â Â Â Â Â Â Â Â and the connection has been established. service
>> + Â Â Â Â Â Â Â Â Â Â Â object represents an instance of a primary service
>> + Â Â Â Â Â Â Â Â Â Â Â that the application is interested in.
>
> It seems it is missing the object path on RegisterAplication to be
> used to call Connected, also I could see some use of this Application
> Agent for regular (non-LE) profiles, but of course the settings would
> have a bit different purpose for those.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>

I discussed this issue with Vinicius before send the initial proposal,
but it is unclear to me if we need to support multiple calls/registers
for the same application or change the parameters. Returning an object
path will be easier to manage the unregister procedure, but once we
export an object path we need to export some methods and properties
for this object. For instance, allow the caller/owner change the UUIDs
and connection parameters.

Is it necessary to pass the application object path in the Connected
method? In my opinion only the object path for the primary services
are enough.

Implement the support for non-LE profiles will be trick, I am not sure
at the moment if we will be able to support BR/EDR and LE profiles
using the same API, but this is something that we already discussed
previously.

Claudio.
--
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


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux