Hello Shane, Including Artem Garmash, the maintainer for libcommhistory and commhistory-daemon, he knows all the details about them. The public repository is on http://gitorious.net/commhistory
> From: Shane Bryan [mailto:[email protected]] > Sent: 06 April, 2011 19:24 > 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? zolkis on IRC, gtalk, gmail, facebook, twitter, and other places > > 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. Surely, so far the Nokia side MeeGo architects have been aware and taking care about it, but after 2/11 is it mainly Arjan? > > 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. Perfectly understandable. We need to do some work before commhistory can be used in MeeGo. > > 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. Internally in Nokia I tried to push through a converged application database in 2009, but email and calendar teams showed good reasons for keeping their stuff in private sqlite databases. I have told the story on this list long time ago in a conversation with Patrick Ohly, I might dig it up and send to you in private. In short, we benchmarked sqlite vs postgresql for such a converged database, with interesting results: they performed very closely, with postgresql having more even system load and more features, plus concurrent access. But that time there was no reason moving away from sqlite and tracker has been the great promise. There are many issues with a common DB at least in a handset environment, with a number of possible solutions (each being a compromise). We could start a separate thread on this, lots of teams are working on it :). > 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. This one depends on the account/service settings, so some interworking would be needed. Commhistory-daemon handles this in Harmattan. I hoped to see a more holistic Qt Mobility API with regards to Accounts, but it went for silos. The way I see the handsets, everything starts with accounts and service settings. This triggers starting up and configuring the enabled services. The communication API's, like all forms of messaging (email, MMS, SMS, IM), and calls, presence, etc could have unified API's wrt accounts (e.g. also SIM cards should be handled as accounts). Actually our private app interfaces are all like this, and these are the ones internally used in Harmattan, not the Qt Mobility API's. I am working on contributing these to MeeGo, let's hope for it. Now the storage is fragmented in Harmattan, and so it is in MeeGo, but again, this is a separate thread. For pure dreaming, see also http://sf2011.meego.com/program/sessions/persistent-graph-based-data-archite cture-meego (I am now part-time exploring various possibilities for the implementation). > > 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? In fact, commhistory-daemon implements a Telepathy Observer on Text and StreamedMedia channels (using telepathy-qt4), and itself uses libcommhistory to store the data. So it would be possible to support events coming from various sources, as far as they respect the ontology (or database schema) supported by libcommhistory. > 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? It is true that commh-d doesn't support other event sources than Telepathy at the moment, since the sole purpose of Telepathy is to unify various event handlings. But it would be possible to support other event sources, if they respect the ontology. On a side note, I don't know what is the current perception of Telepathy in MeeGo, but I assume there is no real alternative for IM, and for VoIP, unless someone wants to integrate libwocky, sofiasip and others into oFono and solve streaming too (and another issue is whether oFono wants this: I assume no). I would like to see a few improvements (Call interface, Mission Control, LTE related changes, etc), and in addition there has been some conflict about the UI models (since Telepathy also brings a UI model, which is not necessarily enough for everything :). But again this is different story (very long). I think telepathy-qt4 is moving towards the right direction of providing high level interface and proper encapsulation, and they are very cooperative on improving it if needed. > > (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) ;) Ultimately tracker used to be the storage integrating all these, and also providing a query language for building data models, but now it's been kicked off :). > > 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)? Yes, ofono would use the storage, and clients access it. I am of course against result sets on DBUS. oFono requirement is that it does not lose events. The clients want to have quick results for building the data models. With sqlite this is tricky to solve correctly wrt locking. Tracker solves it by having Unix socket for transferring the result sets and only one process allowed to access the DB. > > 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? So far it has been this afternoon's talk with Aki Niemi :). You could directly discuss with him about it, I think this should be an oFono decision. > > 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". Doesn't have to "own" it, it should just handle/solve it. >That > should be the domain of either oFono or one and only one system > service, such as commhistory daemon (or similar). In this case it would take the role of commh-d for calls. The point is that after all it is good if Calls are handled separately, since then all resources needed for calls can be partitioned together in a cgroup, and don't pull dependencies from messaging and other parts. I remember when 3 years ago I faced the decision to handle calls and messaging observers together or separately, but that time there was not much talk about the need to use cgroups, so we went for the simpler solution. > 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. I think for the coming release you can just use plain old Linux way, choosing the simplest solution at this time, even if it's not perfect for everything. The world can be redeemed later :). > > > 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. It would take us not too long (maybe 2-3 weeks) to make this, if the Harmattan program permits. I try to push it. > 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, To me it looks like there is big silence on this one here. Honestly I don't know... > 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? Artem could you please take care of updating http://gitorious.net/commhistory ? > 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] Should we follow the process and change the repository?? I have pushed through the open sourcing of commhistory in record time of one week (with some luck and a lot of good will from approvers), but I haven't followed up its afterlife in MeeGo, that was someone else's task as I was continuously overloaded with upcoming Nokia solutions and architecture studies. That embarrassment is over now, that's why I am more active on MeeGo lists nowadays :D. > Thanks for your remarks, and I *do* look forward to working together if > and when it makes sense to do so. Certainly, me too, and please include Artem too into the MeeGo loop :). Best regards, Zoltan > > Regards, > > Shane... > [1]http://wiki.meego.com/MeeGo.gitorious.org#Adding_a_new_project_to_meego.g itorious.org
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
