Hi Arik, On Thu, Feb 2, 2012 at 9:32 AM, Arik Nemtsov <arik@xxxxxxxxxx> wrote: > On Thu, Feb 2, 2012 at 15:07, Anderson Lizardo > <anderson.lizardo@xxxxxxxxxxxxx> wrote: >> Hi Arik, >> >> On Thu, Feb 2, 2012 at 8:19 AM, Arik Nemtsov <arik@xxxxxxxxxx> 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 Sure, Claudio is "taking care" of this document, and will send you soon for early comments. But we want to send to the list ASAP as well. There is draft documents for PhoneAlert/AlertNotification as well. >>> 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. Indeed. Feel free to send patches for those :) For Time/Phone Alert/Alert Notifications services, we will already send using the gatt_service_add() API. > > For IAS/LLS the notification to an upper-level app is missing > (something the new D-Bus API will probably address). Correct. The Proximity Reporter API is already documented in docs/proximity-api.txt, but needs to be implemented. > For TPS, > returning the RSSI is missing (in a read_cb). I thinki this is on purpose. Are you aware that there is ongoing discussions on BT SIG to avoid this "RSSI polling" altogether on future Core spec revision? The plan is then to completely avoid exposing this information at the moment because it may not be more available on future revisions. But feel free to send proposals on how to handle this. We may have issues with too much polling and overhead if RSSI values are sent over D-Bus too often. >> 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. Ok. As I said the code is messy, so I expect comments only for the patches I'll send here :) But feel free to take a look. > > 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. No problem. I agree the most tricky part will be on properly handle notifications. I plan to only handle the "easy" part now , so at least we can work with Time clients which may want to interact with this service. Best Regards, -- Anderson Lizardo Instituto Nokia de Tecnologia - INdT Manaus - Brazil -- 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
