On Thu, 2014-04-24 at 15:28 +0200, Patrick Ohly wrote: > On Wed, 2014-04-23 at 16:08 -0400, Tristan Van Berkom wrote: > > This is my prerogative and I can accept that it is not shared with the > > maintainers of EDS, nevertheless I would still like to caution against > > opening up the SQL tables owned by EBookSqlite to be shared with plugins > > (it may take a little more time in the beginning to flesh out a well > > defined interactive API that satisfies the needs of plugins, but this > > will pay off in better long term stability, anyway this is my opinion). >
Hi Patrick, Sorry if I've slowed you guys down by not replying sooner. I did reread this thread, from what I understand there are two requirements, one of them is to receive more information in change notifications (i.e. perhaps providing the old vcard and new vcard of a given modified contact will solve this completely) and this requirement can be satisfied without any intimate knowledge of the backing SQLite DB (the EBookBackendFile already has all the needed information to emit a better notification to EBookClientViews). The other requirement if I understand correctly is to record change notifications, and we want to persist these in the same DB because in the case of a power loss or crash, it would be nice to have the modifications saved at least until which time they are "claimed" later on by some software which was interested in receiving the change notification - this strategy minimizes the risk of lost "change records". > I agree with you, plugins should not make assumptions about the content > of sqlite database. This needs to be documented clearly. > > However, the goal is not to let plugins access the existing tables. > Instead, the goal is to let plugins create their own custom tables and > update them as part of the same transaction that EBookSqlite uses to > update its own tables. Name clashes need to be avoided, but that is a > minor issue. We might also want to add hooks for DB updates and locale > changes. > > Does this address your concern? Honestly not really no, but it shouldn't stop you from getting things accomplished, perhaps there is a middle path which can be walked. >From what I understand, fleshing out a good API for tracking a history of vcard records/changes is too complicated to be done quickly (there is a lot to consider, is there one global history that is flushed automatically by the EDS backend ? is there a separate copy of the history for every external entity which is interested in later collecting the changes ?). In this case I might propose that a plugin be developed in-tree, sharing a private header file giving the experimental plugin access to some internal functions such as: ebsql_exec(), ebsql_exec_printf(), ebsql_start_transaction(), ebsql_commit_transaction(), ebsql_rollback_transaction() This would allow us to continue development without making premature decisions about the plugin API - the experimental "history plugin" could be usable in it's current in-tree form and not have strong API/ABI guarantees. When the experimental plugin matures and we are finally satisfied with it's API then we could easily adapt it's functionality in EBookSqlite proper - all of this without ever having officially exposed the DB handle in any public API (and without preventing you from using the experimental plugin API in the meantime). Does this sound reasonable ? Cheers, -Tristan _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers