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