I've been pondering this for the last couple days and should have brought it up sooner, I'm looking at the bug regarding fetching UID+REVISION only from the addressbook: https://bugzilla.gnome.org/show_bug.cgi?id=652179 (there is a similar bug open for libecal)
Currently the proposed solution is to extend the EBookQuery language to allow filtering of returned vCards from e_book_get_contacts() and contacts reported from an open view. But currently we already have a patch proposed on this bug: https://bugzilla.gnome.org/show_bug.cgi?id=652172 which (for master) adds the 'e_book_client_view_set_flags()' api that allows configuration of the view and allows the view to report UIDs only (basically doing with an EBookView what one can already do with an EBook directly using e_book_get_contact_uids()) So what should we end up with at the end of the day ? A few reasonable paths present themselves, the first one being we do augment the EBookQuery language: The future with EBookQuery: o Augment the query language to add 'flags' to queries for EBookQuery (and the other query code in libecal which I'm not yet familiar with).. o Add EBookQuery flags for both 'uid-only' and 'uid-and-revision' o Remove the redundant api from my previous patch which adds pointless flags on the EBookClientView (the EBookClientView is created based on a query anyway, so it can absorb the flags of the query and share that api). o Deprecate all forms of e_book[_client]_get_contact_uids() (no reason to maintain a dedicated gdbus code path to return a list of UIDs if the EBookQuery can be flagged to just return a list of uids). That could leave us with a single "flags" api to filter and control both what comes out of EBook apis and EBookView notifications (or we could implement the query language only for calls to e_book_get_contacts() and use our separate flags api to control the behaviour of an EBookView, that would certainly be an undesirable api though). Or... we don't extend the query language, extending the query language with lots of flags means that backends get trickier to support and maintain, rather than adding all of this machinery perhaps we would rather just: o Deprecate the e_book_get_contact_uids() dedicated codepath in favour of something that returns a list of shallow vCards containing only UID and REVISION strings (it could return 2 arrays of strings instead of shallow vcards, whichever). o Implement the new e_book_view_get_revisioned_uids() in the backend side by having a fallback which just fetches all the vCards and filters them down to the UID + REVISION. This way a backend that does not implement the new get_revisioned_uids() vfunc do not return an error, they just (possibly) operate a little slower than backends which implement it in a custom way. o We do the same for EBookView, instead of having a flag that says "only the UID", let it be a flag that says "the UID and the REV"... it would be a "TOC" (table of contents) flag. In this second case we generalize a little and say that "if you only want a bookmark and not a full contact, you get the UID + REV but not the autobiography in the contact details" So one question is, are we being tedious by trying to make separate code paths to handle UID-only and UID+REV filtering or can we say that "returning the UID+REV is fast compared to loading the whole vCard" and just offer one code path to return the UID+REV ? Well, those are my thoughts so far, I'm hesitating between trying to write the whole thing up by augmenting the EBookQuery language or adding a new e_book_get_revisioned_contact_uids() api... I think the latter will take me less time as well as have the benefit of 'just working' on all backends. Cheers, -Tristan _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
