Hello Anderson, On 28/09/2012 12:56, Anderson Lizardo wrote:
Hi Frederic, On Thu, Sep 27, 2012 at 5:59 AM, Frederic Danis <frederic.danis@xxxxxxxxx> wrote:Hi everyone, Here is my proposal for new storage directory structure using ini-file format.Do you know if the INI parser in glib allows for multiple groups with same name?
Following glib documentation:"groups in key files may contain the same key multiple times; the last entry wins. Key files may also contain multiple groups with the same name; they are merged together."
So, I do not think this meet our needs.
In LE we can have services with same UUID (not sure if this is valid for BR/EDR also), and they are differentiated by other means (e.g. a "Description" descriptor with different value, besides the different handle).
For BDEDR, it is easy to retrieve info related to a profile as profile's UUIDs are unique.
Are "Description" descriptors for a profile well-know or implementation dependent ?
Do you think we can use [<UUID>,<Description>] as group name ?
Regarding LE, we have two kinds of storage needs: server profiles, and client profiles. For server profiles, we need to store the attribute database.
Is it possible to save it as we did for SDP records (record entry in profile group) ?
Currently we don't do this, but we need to implement it, or have ServiceChanged characteristic notifying that the service ranges have changed every time BlueZ restarts (which adds overhead as service discovery is triggered on the client side). I suggest we store the attribute database into a "attribute_db.conf" file containing the attribute name/value/uuid triples.
Isn't it possible to save it in [<uuid>] group of device.conf file ?
Additionally, we also need to store
the Client Characteristic Configuration descriptor values (which are
specific to each bonded device), currently stored into a "ccc" file.
We could have one group just for them into attribute_db.conf.
For client profiles, I think the storage needs are specific to each
profile. From memory, only the generic GATT client and the GAP plugin
use storage currently (other profiles eventually need to use storage
to avoid full service discovery every time a bonded device
re-connects). The generic GATT client stores service/characteristics
handles/uuids ("primaries" and "characteristics" files), and the GAP
plugin stores appearance data ("appearances" file).
My first thought for LE data in device.conf is: [<Primary UUID>#<Description>] Handle= Characteristic= Attribute= CCC= I think we can easily add other key entries when needed. Regards Fred -- Frederic Danis Open Source Technology Center frederic.danis@xxxxxxxxx Intel Corporation -- 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
