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

Hi Chen, Lizardo,

2011/12/5 Anderson Lizardo [off-list ref]:

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

I was thinking in using a sort of server_id to distinguish between
services registered among different plugins. That a first idea I have,
I'm going to try to send a RFCs patches during these days. As always,
I'll be updating my git repository at github if you want to follow my
progress.

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

I'll put my hands on this issue.

Regards