[Evolution-hackers] Filtering vCards down to the UID+REV

[Tristan Van Berkom <tristanvb openismus com>]

   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