On Tue, 2014-04-22 at 07:28 +0000, Potrola, MateuszX wrote:
> I have one additional question about updating internal table by this
> new module, should we add some new external API for EBookSqlite to
> create/retrieve/modify backlog entries or the module can operate
> directly on the database using instance of sqlite3 struct from
> EBookSqlite ?
Hi,
there is still required to change the EBookSqlite API, to have an access
to the internal sqlite pointer (thus I'd prefer that all the backlogging
does your module on the sqlite3 database provided by the EBookSqlite).
I do not mind how you will do it (can be either a new function, or an
extra parameter to some signal), I only do not want to expose the
sqlite3 dependency in the public header, thus the pointer would be used
as 'void *', rather than 'sqlite3 *'.
My rough idea would be to add two new signals on EBookSqlite:
gboolean before_add_contacts (EBookSqlite *ebsql,
const GSList *contacts,
const GSList *extras,
gboolean replace,
[void *sqlitedb,]
GCancellable *cancellable,
GError **error);
gboolean before_remove_contacts (EBookSqlite *ebsql,
const GSList *uids,
[void *sqlitedb,]
GCancellable *cancellable,
GError **error);
with the default implementation returning TRUE, like when everything
worked fine. The callbacks should be called in the respective functions.
There are also more things to be changed, like adding the ESource
property for EBookSqlite and consolidate transactions appropriately.
This is only a rough idea, you may come with something better, I
believe.
Bye,
Milan
_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
