Hello, > From: Robin Burchell [mailto:[email protected]] > Sent: 29 March, 2011 22:48 > > On Tue, Mar 29, 2011 at 7:59 PM, <[email protected]> wrote: > > If we agreed to handle libcommhistory by indexing contacts to > tracker, then > > eventually IM/VoIP contacts could continue staying in tracker as well > and > > everything would continue working via libcommhistory. > > I don't mean to throw fuel on the fire, but I have to re-ask something > which was hinted at by Arjan earlier (I think): does anything actually > use libcommhistory yet? If not, it's a bit of a moot point, isn't it?
I don't know who is using it. Commhistory provides Qt models for messaging and call events (the lib), plus a daemon for Telepathy observer for call and messaging channels, notification handling, etc. The code has been part of MeeGo. If not used, then it's work done, work tested, work lost: business as usual. > If libcommhistory is going to be relevant in the open source stack, it > either needs to be used. To be used, someone needs to write the code > for it. That's probably going to be you [you meaning the team working > on it], unless you get very lucky and convince someone else to get > interested in it, and write code using it. Until this happens, it > working, or not working, isn't really a concern for MeeGo, because > MeeGo doesn't use it. If Nokia does, then that would be Nokia's > concern. True. Actually we are trying to extend a bit the scope of libcommhistory, by contributing the associated call and messaging Qt middleware to MeeGo during the coming weeks. Although we cannot contribute any UI related code, after this it will be much easier to fit a thin Qt or QML UI on top of this for call and messaging. This is work in progress, so at this point I would just like to avoid premature killing of libcommhistory as a byproduct of the latest MeeGo architecture changes and it corollaries. When this contribution completes, might put QtContacts and tracker into slightly different light as well, because they all work together nicely and tested (OK, maybe not for the coming release, but hopefully the next). Of course this is only great news if someone is interested to write Qt/QML call UI and messaging UI very easily. It will be of no help for people who want to do the same from scratch in a more complex way. > As far as my understanding of the technologies is, libfolks isn't > related to libcommhistory anyway. It's more similar to contactsd / > qtcontacts, in that it fetches contacts from multiple sources (like > Telepathy) and stuff. The talk was about the need of gathering IM and VoIP contacts (used by libcomhistory) also by the new solution. There is a working solution for it now, which is going to be gracefully ditched, so I expressed my hope that the "workaround" kind-of agreed for libcommhistory would be applicable here as well. Libfolks is not really an alternative at least for commhistory. Indeed, if libcommhistory is not used, then the point is moot, but at least until now it has been part of MeeGo. Of course, we never know for how long we have road under the weels, but keep running until meeting the brick wall. 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
