Hello,
Related to IM/VoIP contacts and social networking contacts:
>
mapping of QtContacts filters to EDS queries, with unsupported filters
implemented by QtContacts after retrieving contacts (slower than filtering in
EDS daemon)
<
Tablet UX choice (according to your previous mail in this thread) sounds
flexible:
1) fetch time contacts aggregation using
1a)QtMobility/QtContacts or
1b) libfolks
2) write time aggregation - if you decide to store contacts to EDS (like we do
now to tracker) and use EDS search/filter capabilities.
It depends on your use cases, performance targets and it is also technology
choice if you'll support fetch time pluggable aggregation - 1a or 1b or both at
the same time,... or focus on 2).
I just wanted to point that it could be useful to put something about this to
http://wiki.meego.com/Architecture/planning/evolution-data-server/QtContacts_storage_plugin
page.
Best Regards,
Aleksandar Stojiljkovic
________________________________________
From: [email protected] [[email protected]] on behalf of
ext [email protected] [[email protected]]
Sent: Tuesday, March 29, 2011 8:48 PM
To: [email protected]; [email protected]
Subject: Re: [MeeGo-dev] migration (back) to EDS - contacts and calendar
Hello,
It is important to address IM/VoIP contacts case. Now, contactsd is storing
them to tracker (https://gitorious.org/qtcontacts-tracker/contactsd) where they
are mapped to communication history.
QtContacts clients fetch/search/sort them along with local contacts (in the
same fetch request).
Best Regards,
Aleksandar Stojiljkovic
________________________________________
From: [email protected] [[email protected]] on behalf of
ext Patrick Ohly [[email protected]]
Sent: Tuesday, March 29, 2011 5:35 PM
To: MeeGo-dev
Subject: [MeeGo-dev] migration (back) to EDS - contacts and calendar
Hello!
Let's be more specific about identifying work which needs to be done.
I've put together some thoughts here:
http://wiki.meego.com/Architecture/planning/evolution-data-server
http://wiki.meego.com/Architecture/planning/evolution-data-server/QtContacts_storage_plugin
http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements
The first page does include a very simplistic comparison of the
different options. I thought about leaving out that part altogether, but
decided otherwise because I believe that listing some of the pros and
cons in public is useful. No flame wars, please.
For contacts and calendar it is fairly obvious where the pain points
are, so let's focus on that for now. I'm interested in getting feedback
on the proposed EDS improvements.
At this point, I have the QtContacts-EDS contact manager working for
reading and writing contacts, as outlined in the page linked to above.
Change notifications are missing. It's just proof of concept
(non-)quality. I suspect that I need to get open source approval first
before publishing it somewhere.
I have not done any prototyping yet with KCalCore, but I expect that
similar improvements as for contacts will be useful for that work, too.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
