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.o...@gmx.de http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers