Hi Claudio,
>>> This patch proposes an unified GATT API for local and remote services.
>>> ---
>>> doc/gatt-api.txt | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 145 insertions(+)
>>> create mode 100644 doc/gatt-api.txt
>>>
>>> diff --git a/doc/gatt-api.txt b/doc/gatt-api.txt
>>> new file mode 100644
>>> index 0000000..2d92f03
>>> --- /dev/null
>>> +++ b/doc/gatt-api.txt
>>> @@ -0,0 +1,145 @@
>>> +BlueZ D-Bus GATT API description
>>> +********************************
>>> +
>>> +GATT local and remote services share the same high-level D-Bus API. Local
>>> +refers to GATT based service exported by a BlueZ plugin or an external
>>> +application. Remote refers to GATT services exported by the peer.
>>> +
>>> +BlueZ acts as a proxy, translating ATT operations to D-Bus method calls and
>>> +Properties (or the opposite). Support for D-Bus Object Manager is mandatory for
>>> +external services to allow seamless GATT declarations (Service, Characteristic
>>> +and Descriptors) discovery.
>>> +
>>> +Service hierarchy
>>> +=================
>>> +
>>> +GATT remote and local service representation. Object path for local services
>>> +is freely definable.
>>> +
>>> +External applications implementing local services must register the services
>>> +using GattManager1 registration method and must implement the methods and
>>> +properties defined in GattService1 interface.
>>> +
>>> +Service org.bluez
>>> +Interface org.bluez.GattService1 [Experimental]
>>> +Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/serviceXX
>>> +
>>> +Methods void Release()
>>> +
>>> + Release this service. At this point, it will not be
>>> + used by BlueZ anymore and can be destroyed by the
>>> + owner. Method applicable to external GATT services
>>> + implementations only (GATT servers).
>>
>> so this is the part I do not like that much. We should not define an interface that has a method that is valid and used only when this is a GATT server.
>>
>> What I am thinking right now (and might need to discuss this a bit further), we leave GattService1 without any methods and use it for both GATT client and server.
>>
>> Then we create some GattServiceAgent1 or GattServiceCollection1 or maybe even GattServer1 that we can register with GattManager1 for the purpose of providing a Release method so that bluetoothd stays in control and can inform applications if it decided to remove a service.
>>
>> I am even fine with allowing to provide multiple services in a collection/server registration. Thoughts?
>
> The "Service Agent" approach was suggested in beginning of our
> discussion. I don't remember anymore why we decided to change it.
>
> Unless you think that it is essential, we could implement the
> Release() method later. When we start the client implementation we
> will have a better understanding of our needs.
> Can I remove the Release() and re-send the patch set?
as long as this is clearly hidden behind our experimental switch, we can get this started without release method.
I want to be cautious since any change would break the GattManager1 interface once we figure out how this should be done best.
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
