On Wed, 2014-04-23 at 08:26 +0200, Milan Crha wrote: [...] > It's like the direct read access for books, more or less, you also > expose private eds API to client side, which should stay server-side > only, but you expect that the client will behave sanely with it. > > I have the same expectations for the EBookSqlite plugin(s), thus, if the > plugin will follow the rules, then I do not see any problem in exposing > the sqlite table. It has its advantages to access the same table, thus > I'm all for it.
Hi Milan, I don't altogether agree with your analogy, DRA is offered through the EDataBook APIs yes, and those APIs need to be better protected indeed, it's hard to police who has access to calling them, however the DRA is only supposed to ever be accessed by API/ABI stable user facing APIs (i.e. we *expect* that users will use DRA via EBookClient APIs, and we reserve the right to break API in libedata-book so long as we preserve the functionality of stable user facing APIs - arguably the EBookBackend entry points for people to develop plugins should also be a stable API but are not quite there yet). That said, even though I don't quite agree with your analogy you do make a fair point, in my point of view we should be striving to strengthen our API and improve control over what EDS code can be leveraged by third parties, thus limiting what is considered a valid use case of EDS. 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). Best Regards, -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