> Ingo Klöcker wrote:
>
> On Monday 22 March 2010, Will Stephenson wrote:
>> On Sunday 21 March 2010 23:28:08 Shaheed Haque wrote:
>> > The next questions should be which is the preferred lineedit, and
>> > which is the preferred search dialog. However, I am beginning to
>> > wonder if, given the Akonadi resource, we should not just use this
>> > for
>> > 
>> > all the UI stuff? If we did:
>> >         - There seems to be a some missing steps in how "Edit
>> > 
>> > Completion Order" is handled for lineedits.
>> > 
>> >          - I assume the "Search for Addresses in Directory" becomes
>> > 
>> > superflous becuase the base "Select Recipient" dialog could just be
>> > enhanced as I originally planned from a UI point of view, but now,
>> > the LDAP resource just looks like another address book.
>> 
>> Was there a strong rationale for having a direct-to-directory-search
>> in the UI, bypassing KResources, (and now Akonadi)?  For example,
>> because these would mandate making local copies from the LDAP
>> database of maybe tens or hundreds of thousands of addresses (into
>> Akonadi, and now Nepomuk, as Contacts), with resulting performance
>> and I/O costs?
>> 
>> If so, what do we want to do in future?  Is there/will there be an
>> Akonadi way to do a lightweight query passthrough to server side
>> search only?
> 
> Yes. This is also mandatory for server side searches on IMAP. Akonadi
> does/will support this. Unfortunately, I cannot give you details as I
> know Akonadi only from the outside.

That was a concern for me too, so glad to see it is not an issue. I imagine 
that the LDAP resource might end up with a disk "cache" in Akonadi/Nepomuk?

At this point, perhaps it makes sense to discuss what I think the eventual 
behaviour of the addresslineedit control AND "Select Recipient" dialog 
should be (i.e. where I would like to try to get to):

1. The "Edit Completion Order" dialog should control both.

	- It might in due course also choose *which* sources are to be
	involved, possibly in an identity-sensitive manner - though I'm not
	especially interested in that.

2. The searching should be done as much as possible for kabc and LDAP 
resources in the same way, e.g. in terms of search criteria. The results 
should be a single set of results (though tagged by source, like the 
addresslineedit does today).

3. Recent Addresses should be treated as a third searchable resource.

4. My preference is for incremental searching, at least by default. I 
realise that large LDAP lists might stretch thsi, but for the vast majoirty 
of users, I suspect it will just work. As for those who work in megacorps 
(like me), well, I'll find out how practical that is soon enough!

Feedback welcome as always,

Thanks, Shaheed
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/