On Thu, Feb 2, 2012 at 01:12, Anderson Lizardo <anderson.lizardo@xxxxxxxxxxxxx> wrote: > Hi Arik, >> This series looks good overall. Are you planning to go ahead with it >> (with a non-RFC series)? > > Sure. This will happen in the very near future (at most next week). > But for now we will drop the "providers" patches, because we are about > to also send D-Bus API that implements the functionality externally. Does this mean the server-application operating over D-Bus would be able to register read/write callbacks on specific attributes? 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. > > But even with the initial implementation, most Time clients will be > supported just fine. They will just not be able to update the phone's > own time or be notified of manual changes to the phone time (this will > be supported with the D-Bus API). Ok. > We plan to have everything which was in "providers" implemented on > external a Agent which communicates over D-Bus. This is necessary to > avoid introducing extra dependency on BlueZ for each platform we may > support. > > We will send a RFC for this Time Agent API real soon. Please comment :) Will do. I am interested in adding an implementation of an NDCS server to the BlueZ time server. It would be nice if you take this into account in the Time Agent API (updating the DST offset from D-Bus). The same is also required for the Local Time Information characteristic in CTS. 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
