[Evolution-hackers] Addresbook query result ordering

[Tristan Van Berkom <tristanvb openismus com>]

Hello again,

    I've been looking into the possibility of getting ordered results
from the EDS addressbook (which is currently unsupported in any shape or
form afaict).

First off, is anyone working on this right now ?

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).

    Of course then, you would only get one sort order, which is still
    better than nothing but... of course you would probably want to
    order some queries/views differently than others.


Thoughts ? any vital details which I may have missed ?

Cheers,
             -Tristan