On Tue, 2014-04-22 at 13:53 -0400, Tristan Van Berkom wrote: > Sorry to interject, I don't have time to write such a lengthly email, > but I would like to warn against exposing the database pointer in the > EBookSqlite API to the world.
Hi, no problem, I was waiting for your insight, to be honest. > Handing out access to the internal DB handle seems to be an open door to > a world of trouble (I can envision bug reports going INVALID because > said user has some kind of non-compliant plugin that is messing directly > with the tables *owned* by EBookSqlite, or creating tables that > EBookSqlite might try to create in a future EDS release)... in other > words, EBookSqlite can only ensure the stability/reliability of it's DB > if it can at least insist to be the only API that is ever used to access > the said DB. I do not consider this a problem. Any change can cause similar trouble, being the sqlite table accessible from outside or not. All that stands on an expectation that the hypothetical plugin will behave sanely and will be good to others. That might mean that the plugin will create its own tables with some prefix, like plugin name, and so on. Ideally, the plugin may not touch the tables of EBookSqlite directly, but only through the API. Just implicit basic rules. You can always get "malicious" software, of course, but then the only real way to deal with it is to get rid of that malicious software. 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. 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