On Wed, 6 Apr 2011 12:44:59 +0000 <[email protected]> wrote: > Hello, > > Sorry that I had to drop off the meeting before it got interesting > about libcommhistory.
Me too, and sorry I didn't know you were there or that you were associated with the libcommhistory project. What is your IRC nick? > 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. Good to know. Would be good to pass this information on to the architecture team so that the don't completely overlook the viability of it. > 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. Agreed. > If I understood it right, there was no decision about communications > history storage, so it was left up to the dialer people. Yes, though I will admit, I have not yet caught up with all the resulting emails from that thread, so I very likely do not know all that has been "agreed" to. But in so far as dialer today, for 1.2, given that libcommhistory and commhistory daemon could not be demonstrated to work (in my own testing on the iCDK with public images) for receiving and storing call history events, *and* that the movement towards EDS was inprogress, I decided that making it a functional dependency for dialer was not ideal at this time. > 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. One observation, based on feedback from the extended handset team here, is that while it was a fair overlap with QMF (and a bit less with QMessaging), it lacked the ability to track email communication events/history, which is a key (and used) element of the existing MeeGo reference apps for Email and SMS. Yet QMF/QMessaging has no concept of Call logging/history itself. It would really be good to see a convergence between these so that all communication event types can be stored and retrieved through a common API. Moreover, the retrieval would need some form of Authorization handshaking to ensure the ability to provide Privacy compliance and enforcement between applications installed from 3rd parties, and the communication history. > 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. My guess is that this will become necessary if the scope of libcommhistory is to be as complete as it's name suggests (implies access to history of all communications). As noted above, email is one such gap, that, to my knowledge, does not have any Telepathy service/interfaces for, and may not be stored in tracker (though I really have no idea actually). More specifically, unless I miss-read the code, libcommhistory and commhistory daemon are purely Telepathy based, and so, unless Telepathy provides an interface for it, libcommhistory can't "get" the event, is this correct? If so, this presents a limitation to feature expansion unless you can work out how to plug in event tracking for non-Telepathy based sources of communication, no? Does libcommhistory have the ability or scope to do so today? > (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. Maybe for the N900, but on the iCDK with the IFX modem using oFono and the Telepathy-Ring package from MeeGo Trunk OBS, I definitely could *not* get it to register *any* form of call event handling. If you think it should have worked, I'd be happy to have you help debug the issue with me off list on IRC some day. > In addition, it integrates knowledge about both calls and messages, Except emails... Oh and what about from various social media sources like Ovi, Facebook, Twitter, etc...? I'm sure at some point that could become a desired form of communication events to be stored (I've seen crazier requests and ideas) ;) > 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. No doubt. And trust me, I definitely am not interested in re-inventing the wheel here. Neither do I "call the shots" on the platform architecture :P > 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. Meaning what exactly... that ofono does the storage and other agents can query it out of band (not using an oFono DBus api to saturate the bus with query results)? > 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. Do you know the status of this "plain sqlite storage from ofono"? Is it in a tagged version of oFono yet? > 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, Not sure a call manager, or any other app, should own "storage". That should be the domain of either oFono or one and only one system service, such as commhistory daemon (or similar). The fact that dialer is doing it today is only a function of the fact that we had nothing else when we started this, and nothing, yet has appeared that can meet all the needs, not just call events. > 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. I think we agree in principle, but we lack complete execution and capabilities yet. I will also add, that since the mid-February announcement from Nokia, there has been a lot of uncertainty regarding which of the projects it started open-sourcing, would actually continue to exist and have active development. With out this, inclusion into MeeGo would be a pipe dream. Only packages that have active development and/or designated MeeGo maintainers have any chance of being part of the system. At the time I first even learned of libcommhistory, the last commit was in late December 2010. I see now that there have been some changes in mid March. Does that indicate something that the MeeGo architecture team should be aware of as far as project viability outside of Nokia? BTW, I never saw an announcement about libcommhistory, nor did anyone ever ping me to consider using it for call history storage/retrieval in place of what I was already doing. Given that it is not under any of the MeeGo projects in gitorious, I'm not sure how I would have stumbled on it either. If it is the intent that it be a part of the MeeGo platform middleware, I suggest looking into having it at least referenced/linked from one of the meego.gitorious.com [1] Thanks for your remarks, and I *do* look forward to working together if and when it makes sense to do so. Regards, Shane... [1]http://wiki.meego.com/MeeGo.gitorious.org#Adding_a_new_project_to_meego.gitorious.org _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
