Re: [Evolution-hackers] Addresbook query result ordering

[Patrick Ohly <patrick ohly gmx de>]

On Mon, 2012-10-15 at 20:59 +0900, Tristan Van Berkom wrote:
> Secondly, I see three potential ways of approaching this problem and I
> wonder which way would be preferable.
> 
> These are the possible avenues I'm aware of:
> 
>   a) Extend EBookQuery API
> 
>      This seems the most natural way to go about it, as I see it a query
>      can contain multiple query terms and a single 'sort order' for the
>      results; i.e. something like:
> 
>    e_book_query_set_order (query, EContactField, AscendingOrDescending);
>
>      However, the EBookQuery does not contain multiple terms, instead it
>      contains... multiple queries, which would make the API quite awkward
>      since it would never make sense to have a query with more than one
>      order defined for it's results.
> 
>      Modifying the query also has other drawbacks, it seems some backends
>      like to send the serialized query expressions over the network,
>      perhaps backwards compatibility would become a serious issue here
>      (I've not investigated very far into this).
> 
>   b) A new set of query apis
> 
>      This might be the right choice considering drawbacks of 'a', in this
>      case we could introduce an entirely new set of apis concerned with
>      getting results from the addressbook.
> 
>      so methods such as:
> 
>    e_book_client_get_contacts (book, query, ...)
> 
>      would receive a complimentary:
> 
>    e_book_client_get_sorted_contacts (book, query, sort_field, ASCEND...)
> 
>      possibly deprecating all of the orderless apis which preceded
>      these new apis along the way.
> 
>      This has the obvious disadvantage of implementation difficulty,
>      i.e. EDS has still not been ported to use the new gdbus-codegen
>      tool so all of that d-bus stuff would need to be done by hand
>      (possibly less overall effort to just port to gdbus-codegen first).
> 
>      One upside to this is that backends which don't yet support the
>      sorted results could fall back on existing APIs, possibly by
>      introducing an EBookBackendSortable interface or such
>      (question still would remain... how to advertise at runtime
>      whether the sorting is supported by the active backend, perhaps
>      via the 'capabilities' backend property).
> 
>   c) The least attractive and easiest way would be to simply add an
>      api to EBookClient telling it "in what order should you sort
>      the addressbook" (or, an ESourceExtension configuring the sort
>      order).

There is a forth option:

d) add sorting to EBookView and leave e_book_client_get_contacts() as it
is.

Extending EBookView might be easier than extending EBookQuery.

Note that when adding sorting, it also makes sense to add a "maximum
number of contacts" parameter. Without sorting, that value is useless
because is not predictable which contacts will be included in the
result. With sorting, it becomes possible to populate a fixed-size view
without having to receive all results.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/