On Wed, 2011-07-20 at 18:28 -0400, Tristan Van Berkom wrote:
> 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.
I've got a patch up on the bug[0] now which adds
'e_book_get_revisioned_contact_uid_list()'
That works the same as e_book_get_contact_uid_list() except
returns 2 lists (one with the corresponding revision strings),
EBookBackendSync provides a default implementation for this,
any backends that are not an EBookBackendSync will cause
an error to be reported (unless they get implemented of course).
Not sure if this exactly the right direction but it seemed more
straight-forward than extending the EBookQuery query language for
the moment, let me know if this should be done differently.
Cheers,
-Tristan
[0] https://bugzilla.gnome.org/show_bug.cgi?id=652179
>
> 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
_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
