On Di, 2011-05-17 at 14:52 +0100, David Woodhouse wrote: > On Tue, 2011-05-17 at 15:44 +0200, Patrick Ohly wrote: > > On Di, 2011-05-17 at 14:06 +0100, David Woodhouse wrote: > > > On Wed, 2011-05-11 at 10:27 +0200, Patrick Ohly wrote: > > > > > > > > If QtContacts-EDS is ever meant to work with a) non-file backends or > > > > b) a file backend which has longer IDs (perhaps because they were > > > > created before upgrading to EDS with the 32 bit patch), then hashing > > > > will be needed again. > > > > > > > > I think we can rule out a) for MeeGo, at this time at least. > > > > > > We are actively working on adding other back ends, for example for use > > > with Microsoft Exchange (via both EWS and ActiveSync). My primary focus > > > was MeeGo 1.3, but there are those who need it on 1.2 too. So I don't > > > think you can rule it out so easily. > > > > Do they need it in combination with QtContacts? > > Hm, if we stick to the plan of using SyncEvolution for the ActiveSync > calendar and contacts, then I suppose we don't need a non-file back end > at all in 1.2.
Right. > For 1.3 we'll definitely have the EWS support, and that includes an > EDS-EWS contacts back end. We'll want that to work in whatever the UI > uses, which may still be QtContacts that that point? That's my assumption. Otherwise QtContacts-EDS as a whole isn't needed. > On the other hand, doesn't QtContacts assume that the full addressbook > is local and enumerable? I guess you could write a manager which runs a query and presents the result with ephemeral numbers assigned to each item. But that is a different use case that'll have to be handled differently. The problem with persistent UINT32<->String ID mapping doesn't occur in this case. I still think an efficient overall solution should avoid the mapping in the main use case. > So the online queries that we do for address > completion in EWS/LDAP/etc aren't supported at all, and clients may want > to be using EDS directly? That's of course always a possibility. -- 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 MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
