RE: [PATCH 1/2] Provide return status in gatt_service_add function

Anderson,

-----Original Message-----
From: Anderson Lizardo [mailto:anderson.lizardo@openbossa.org]
Sent: Monday, December 05, 2011 1:37 PM
To: Ganir, Chen
Cc: Santiago Carot; linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 1/2] Provide return status in gatt_service_add
function

Hi Chen,

On Mon, Dec 5, 2011 at 7:10 AM, Ganir, Chen [off-list ref] wrote:

quoted

What do you mean restoring the attribute handles ? Each of the

profiles registers its own services when the plugin is loaded,
according to the load order (which I assume will not change).

There is no guarantee in the load order. As we add more plugins, you
can't predict the order the plugins will be loaded.

quoted

When a profile registers its attributes, it can specify callbacks for

read/write which are actually function pointers. How to you plan to
support this?

Only attribute *handles* are to be stored (for now). The mapping could
be based on service+characteristic UUIDs (but we need to pay attention
if we have multiple services with same service and characteristic
UUIDs; for this case, I'm not even sure how the client knows which one
to use).

quoted

In addition, who will be responsible for reloading the database and

populating the values (profile plugin or bluetoothd core) ? how do you
synchronize them?

My suggestion would be to implement this in attrib/gatt-service.c so
gatt_service_add() could load attribute handles from storage
transparently. This could also avoid changing every profile.

Note this is only for *server* roles (e.g. PAS server, TIP server, PXP
reporter etc.).

I'm not sure what you mean with synchronization. The attribute handles
are to be stored when the service is registered (and you can't change
them after registration).

quoted

Do you have an RFC or a simple design description which will allow

reviewing?

No. I am not working on this currently. This discussion started from
an idea from Santiago to how to handle registration failures (see
initial post), to which I responded that we may want first to address
attribute handle storage to make sure handles stay the same during
device lifetime (until it is factory reset).

Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Thanks.

Chen Ganir.