Hello, Sorry that I had to drop off the meeting before it got interesting about libcommhistory. I'd like to add some points about libcommhistory with regard to to MeeGo dialer (not for the coming release, but for longer term).
1. libcommhistory started using sqlite as a storage in the beginning, and it could be added as a possible backend. 2. About tracker. IIRC tracker is not going completely away from the next MeeGo release: it will still index content. The decision was that among others, for now contacts will be stored in EDS. If I understood it right, there was no decision about communications history storage, so it was left up to the dialer people. One solution to use libcommhistory is to index the needed contact fields to tracker, and use libcommhistory as it is. Performance-wise nowadays you can smoothly scroll through lists of >10000 items, thanks to the cursor based access (see queryrunner.cpp). Probably this would be much-much worse if contacts were to be fetched from a different database (EDS), and a manual join was to be made without indexes. 3. libcommhistory provides Qt data models for SMS+Class0 SMS, MMS, Call (CS+VoIP), VoiceMail, IM, StatusMessage. It is pretty easy to use, check e.g. callmodel.h, smsinboxmodel.h, etc. Probably it is possible to split these models, but the database access code shares a lot of commonalities, which is why they are provided together. If we want to support multiple storage backends, or even split heterogenous backends, we need to generalize the DB interface (currently it is abstracted by trackerio.h, take a look, almost good enough). This would be quite some work, especially with a buffered of cursor-based access. If development time is important, and libcommhistory was to be used, shortest would be to use tracker as storage backend. 4. Libcommhistory and commhistory-daemon is only a part of Harmattan call and messaging middleware, and we have (currently) closed middleware components for call UI, call history, dialer, and then messaging UI. That is why the libcommhistory story looks incomplete from MeeGo side. I hope we could contribute some, or all of this middleware code, which ought to have come together with libcommhistory. But even without these, libcommhistory is usable also alone. In addition, it integrates knowledge about both calls and messages, so when looked from MeeGo side it is partially out of scope to anyone who is interested only in certain type of calls, or messaging, therefore wanting a simpler solution for that slice of the problem. But if you will ever need integrated experience, you'll probably end up with similar solution as libcommhistory. 5. We've had a short discussion with ofono people on how to store events from ofono. They would prefer a direct access database, be it tracker or sqlite or other. For the coming release the simplest alternative would probably be just to use a plain sqlite storage from ofono, and access it from the dialer using QtSql, or call-history DBUS interface of ofono. 6. For longer term I think at mechanisms/data models level MeeGo should support both separate UI's and integrated UI experiences. In Call case, since we will have possible handovers between CS and LTE (VoIP) for instance, even separate UI's would need a single call manager, which would handle the storage, states, transactions, accounts (SIM, VoIP) and backends, domain selection in LTE, handovers (in LTE and enterprise use cases). You'd just need a very thin QML or Qt UI on top, or even multiple parallel UI's (think automotive, or multimodal use case). Similar architecture would be possible for messaging. Best regards, Zoltan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
