Re: [Evolution-hackers] ebook API

[Chris Toshok <toshok ximian com>]

On Wed, 2003-12-10 at 10:09, Ross Burton wrote:
> Hi,
> 
> In writing contact-lookup-applet I've found some issues with the ebook
> API:
> 
> e_book_async_get_book_view(...) doesn't allow me to specify the maximum
> number of records, whereas e_book_get_book_view(...) does.  Should the
> async version be extended to take the extra argument?  This looks like a
> trivial patch to me.

Yeah, that was basically laziness on my part.  I didn't expect many
people (anyone, really) to use the async api so I figured it'd be less
work to not change the parameters from the old get_book_view ebook call.

> ECardCursor has gone! I was planning on using it (or something similar)
> in contact-lookup-applet to handle the case where the address book has
> many contacts which match the typed name.  It's not a common case, but
> if I pointed my applet at a large LDAP server and typed "John",
> e_book_get_contacts() could take some time to retrieve the data and
> create the EContacts for the completion.  I will be switching to
> e_book_async_get_contacts() to reduce UI blocking, but this could still
> involve creating a large lists of contacts.  Is there a better way I've
> missed?

As Dan mentioned, a book view is definitely what you want if you want to
avoid blocking the UI.  The old CardCursor stuff basically fit someplace
in between the current get_contacts() and get_book_view() on the
ease-of-use/blocking-the-ui spectrum.

Chris