Re: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

[Arik Nemtsov <arik@wizery.com>]

On Thu, Feb 2, 2012 at 15:07, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi Arik,
>
> On Thu, Feb 2, 2012 at 8:19 AM, Arik Nemtsov <arik@wizery.com> wrote:
>> Does this mean the server-application operating over D-Bus would be
>> able to register read/write callbacks on specific attributes?
>
> Actually the API will be more high level, and hopefully Profile
> agnostic, so it can be reused between profiles.

Maybe you have some preliminary suggested documentation? It would be
interesting to take a look

>
>> It would be nice to get a sense of the API soon. We're planning on
>> implementing several GATT servers. Namely - ANS, PASS, IAS, LLS and
>> TPS. This can obviously effect the design.
>
> It would be interesting for us to cooperate on this then. IAS/LLS/TPS
> are implemented on BlueZ upstream already (check proximity/* files).

It would indeed be nice to cooperate :)
As for IAS/LLS/TPS - I think maybe a rewrite using the higher-level
gatt_service_add() API is in order.

For IAS/LLS the notification to an upper-level app is missing
(something the new D-Bus API will probably address). For TPS,
returning the RSSI is missing (in a read_cb).

>
> ANS and PASS have skeleton code and initial implementation (which I
> will send soon to the list once I clean it up) on my development tree
> (warning: it is currently messy and outdated, and needs cleanup):
>
> git://gitorious.org/~lizardo/bluez/lizardo-bluez.git (branch
> for-upstream-phone-alert)

It seems I can't get to gitorious right now (seems to be some planned
maintenance). I'll definitely take a look once I can.

>
> Our current design is to have both ANS and PASS grouped into a
> altert/* directory.

Sounds good.

> I plan to send initial "dummy" implementations of NDCS and Local Time
> Information as well, but if you already have them implemented, feel
> free to send at least some RFC here.
>
> But you can extend with further functionality after we have the
> initial services upstream.

NDCS adds very little code. My main concern here is updating the
DST-change time periodically from the server-app.
Seems to me it's better to wait for your proposed skeleton implementations.

Regards,
Arik