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