On Mon, Nov 17, 2014 at 2:09 PM, Patrick Ohly <[email protected]> wrote: > On Mon, 2014-11-17 at 12:58 +0200, Von Dentz, Luiz wrote: >> Hi Patrick, >> >> On Mon, Nov 17, 2014 at 10:30 AM, Patrick Ohly <[email protected]> >> wrote: >> > On Fri, 2014-11-14 at 22:51 +0000, Xu, Martin wrote: >> >> Hi Kis: >> >> Thanks for your comments on NTB, and in general, we have same opinions >> >> from technology. >> >> Please see my comments. >> >> > The bigger problem is that CAPI [1] does not support the features >> >> > promised >> >> > in the architecture slides [2], so it is impossible to be used in >> >> > Crosswalk >> >> > extensions using PBAP and MAP for instance. Instead we need to directly >> >> > use >> >> > BlueZ, and that is what I am doing now. >> >> Please tell me detail what is the features promised in CAPI and not >> >> supported? >> >> And what is the detail about why you can't use PBAP and MAP? >> > >> > Because PBAP is not part of the CAPI? See also my email from October >> > 29th that no-one replied to: >> > http://permalink.gmane.org/gmane.comp.handhelds.tizen.devel/4677
Yes, PBAP/MAP are not part of CAPI, I was referring to this for missing features from CAPI, compared to what's promised by the architecture slide. >> >> Btw, perhaps PBAP does not need to be part of the CAPI if >> syncevolution API provides the same functionality, IMO either we have a single usable CAPI, or not. If we can cover functionality by various interfaces, then I also vote for using DBUS directly (e.g. from Crosswalk extensions), and make DBUS usable from a security point of view. IMO it's not a rocket science to program with DBUS, albeit slower - but don't forget this needs to be done per platform and not per app... so it's not a big issue. I prefer lean platform development to an "easified" platform development with lots of layers introducing more and more latency. > > SyncEvolution needs to talk to something which does the actual PBAP > transfer for it. Currently that's obexd via the obexd D-Bus API. As I > pointed out, using CAPI instead doesn't seem to be an option at the > moment. > > This might be changed, but before investing work into that (both in NTB > and SyncEvolution), I'd like to hear a convincing argument why that > would be a better solution overall. > > How multi-user support gets implemented is part of the bigger picture. I am implementing now call history (CH) from PBAP, and it's similar to contacts in that the same client API can have: - transient data sources like phones connected via BT, for which apps will get the contact/CH list directly through PBAP, not being stored anywhere in between (also o think about flash wear, user/device/session separation etc) - local persistent data sources like native contacts/CH databases, which are user-specific. I started with implementing CH using PBAP, since it's the main IVI use case, and local call history coming from ofono is a bigger topic, and needs a proper per user database, fed from the same source (local modem + ofono), with less relevance than PBAP at the moment. Contacts is similar, but in addition, contact may have online data sources as well, both transient and persistent. Messages (at least SMS and MMS) is similar as CH. It's not important in which daemon these would be run, but they have similar requirements, and I'd welcome a solution which would provide per user access to CH, Contacts and Messages, facading multiple transient and persistent data sources transparently. On the client API, it would not provide a DB API, just a sync API, much alike to the W3C DataSource API (dropped in favor of IndexedDB), with the reasoning being that modern apps tend to implement new data models, and would like to manage their own indexes and queries, perhaps database. And for the traditional data models, latency through the many layers may be worse than fetching/syncing data into a local DB or indexing into memory (either in native or JS apps) and process from there, in the most typical sizes of user deployments (less than 10000 records for contacts and messages, and less than 500 for call history). > >> but I guess that >> would mean synchronizing missed calls, etc, which I guess >> syncevolution currently ignores. Regarding Crosswalk I would have >> guessed it would make sense to just use D-Bus directly so it would >> work with any platform using BlueZ, if that is not possible in Tizen >> then we have the same problems listed bellow. Crosswalk extensions currently use DBUS interfaces directly (oFono and BlueZ). > > Crosswalk uses a Tizen-specific native component, the phoned, which > talks to obexd via D-Bus. It's in the same situation as SyncEvolution. > Long term I think the contact handling in phoned should get replaced > with SyncEvolution's, but for now support both approaches in Tizen. phoned only supports a few use cases of Modello Phone app. The W3C implementations don't use phoned any more: the Telephony API needed a lot more functionality than what phoned covered and is using ofono DBUS interfaces directly. Similarly, CH handling from phoned is moved to an extension, directly using DBUS for accessing PBAP. Similarly, W3C Contacts API implementation would also use PBAP via direct DBUS access. All until a more synergistic solution like the one suggested above is done. Best regards, Zoltan _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
