On Tue, 2011-03-22 at 10:15 +0100, Patrick Ohly wrote: > On Di, 2011-03-22 at 09:04 +0000, [email protected] wrote: > > > From: Patrick Ohly [mailto:[email protected]], sent on 22 March, > > > 2011 > > > 10:35 > > > Option 2 seems like a reasonable approach to me, if we can make it so > > > that the call history database is self-contained and merely mirrors the > > > subset of the contact data in read-only mode that is relevant for a > > > quick list of results, with more details fetched on demand from the > > > main > > > contact database. > > > > Yes, and same for messaging (IM+SMS). This assumes the storage for IM + SMS > > + > > call history is still tracker. Strictly speaking, the requirement is just > > that > > contacts and the above should be stored in the same DB, whatever it is. > > Just > > out of curiosity, what would prevent support in EDS for IM+SMS+callhistory?
It should be just a matter of time. > > It's designed around single daemons for contacts and calendar. IM+SMS > +callhistory could be mapped into the calendar part, but that wouldn't > solve the problem of correlating the two data sources. It should be more about exending EContact to incorporate additional fields. Call history could be extended into EContact. Just for example, the "birthday" calendar of EDS relates contacts into a calendar, some to look for correlating data sources, may be extending along those lines could help to co-relate sources. > > I also suspect that the EDS APIs simply wouldn't support the additional > use cases well enough. The goal is to keep EDS in MeeGo aligned with > upstream EDS, to avoid maintaining a fork of it for Handsets in MeeGo. I'm sure, we can extend EDS with the upstream support. I could help in where ever required. -Srini. > > > About shared models and caching (and then supporting heterogenous data > > sources) we are doing some prototyping now, I hope to share more on the > > MeeGo > > conference, but this won't work very soon, so it's out of question for now. > > That sounds interesting, please share as soon as you can. In case it > wasn't obvious, I'm trying to keep the discussion about this > architecture change public instead of working on a fully-formed plan in > private exactly because I hope to get such additional feedback and > pointers. > > Unfortunately private reasons prevent me from coming to the next MeeGo > conference. > _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
