15692 2007-10-25 12:25:05 -0700 Gtk Api to check database support and change the path 2009-09-07 03:25:59 -0700 1 1 1 Unclassified WebKit WebKitGTK 523.x (Safari 3) All All RESOLVED FIXED Gtk P2 Normal --- 27899 1 christian webkit-unassigned gustavo jmalonzo oldest_to_newest 59458 0 christian 2007-10-25 12:25:05 -0700 The new database storage feature stores databases hidden in the folder $XDG_DATA_HOME/webkit/databases. There is no api to test wether the feature is available at all or to to change the path respectively. 59460 1 16863 christian 2007-10-25 12:31:21 -0700 Created attachment 16863 A proposal of a possible api This patch implements webkit_has_database and webkit_set_database_path. This concept is a bit unusual for Gtk+ and not necessarily what we want. Discussion about this is very welcome, especially if you have concrete plans to use this feature. 59572 2 jmalonzo 2007-10-26 14:02:01 -0700 *** Bug 15612 has been marked as a duplicate of this bug. *** 88408 3 zuh 2008-08-13 10:34:00 -0700 The settings API in WebKit-GTK+ seems to be unsuitable for this, since the path is (as far as I can tell from the code) expected to be a global. There isn't a global version of the settings API (that I know of) but looks like this is at least one instance where we would need one. One improvement over the current one might be to use g_get_prgname() instead of hard-coded "webkit" in order to not clash between eg. a browser and some other application using WebKit. It's already used in the UA string generation for example, which btw is another candidate for global setting (though maybe that would have use-cases for per-view configuration). Third one I can think of is some cache settings. I'll refresh the patch to be applyable and move it to webkitprivate.h (there seems to be some other API which is under discussion too), but just to allow people to easily import it if they need the functionality, not for inclusion. 88410 4 christian 2008-08-13 10:47:19 -0700 (In reply to comment #3) > One improvement over the current one might be to use g_get_prgname() instead of > hard-coded "webkit" in order to not clash between eg. a browser and some other > application using WebKit. It's already used in the UA string generation for > example, which btw is another candidate for global setting (though maybe that > would have use-cases for per-view configuration). Third one I can think of is > some cache settings. I have to disagree with using g_get_prgname(). Usually we want to share things like this. While it should be an optional feature to use for instance databases only in the context of one application, it's not normally very helpful. 88415 5 zuh 2008-08-13 11:19:01 -0700 (In reply to comment #4) > (In reply to comment #3) > > One improvement over the current one might be to use g_get_prgname() instead of > > hard-coded "webkit" in order to not clash between eg. a browser and some other > > application using WebKit. It's already used in the UA string generation for > > example, which btw is another candidate for global setting (though maybe that > > would have use-cases for per-view configuration). Third one I can think of is > > some cache settings. > > I have to disagree with using g_get_prgname(). Usually we want to share things > like this. While it should be an optional feature to use for instance databases > only in the context of one application, it's not normally very helpful. Hmm, I suppose you are right. I can imagine for example an music store using the storage area in view embedded in a music application and in a browser session. Then there's also the question of when this is allowed to be changed? At least it'll ASSERT if a database is open at the time, but does it make any sense to change it after application startup? 113867 6 gustavo 2009-03-16 07:16:11 -0700 Hey, (In reply to comment #3) > I'll refresh the patch to be applyable and move it to webkitprivate.h (there > seems to be some other API which is under discussion too), but just to allow > people to easily import it if they need the functionality, not for inclusion. Have you been able to do this work yet? Still plan to do it? =) 120361 7 jmalonzo 2009-05-07 17:05:56 -0700 (In reply to comment #6) > Hey, > > (In reply to comment #3) > > I'll refresh the patch to be applyable and move it to webkitprivate.h (there > > seems to be some other API which is under discussion too), but just to allow > > people to easily import it if they need the functionality, not for inclusion. > > Have you been able to do this work yet? Still plan to do it? =) Setting database paths are currently supported in WebCore settings so it might be a good idea to make this a setting (which also make this a per-WebView thing in the API). Apps who want a specific location can just set it to the location they want - and we can just default it to what it is now. I can cook up a patch if nobody's working on this right now.. 120371 8 jmalonzo 2009-05-07 17:51:55 -0700 (In reply to comment #7) > (In reply to comment #6) > Setting database paths are currently supported in WebCore settings so it might > be a good idea to make this a setting (which also make this a per-WebView thing > in the API). Apps who want a specific location can just set it to the location > they want - and we can just default it to what it is now. Correction: setting database paths in Settings is only for localStorage. 145122 9 jmalonzo 2009-09-07 03:25:59 -0700 You should be able to set the database storage path now that bug #27899 has been fixed. 16863 2007-10-25 12:31:21 -0700 2007-10-25 12:31:21 -0700 A proposal of a possible api database-path.diff text/plain 1700 christian SW5kZXg6IFdlYktpdC9ndGsvQXBpL3dlYmtpdGd0a2dsb2JhbC5jcHAKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g V2ViS2l0L2d0ay9BcGkvd2Via2l0Z3RrZ2xvYmFsLmNwcAkoUmV2aXNpb24gMjcwNTIpCisrKyBX ZWJLaXQvZ3RrL0FwaS93ZWJraXRndGtnbG9iYWwuY3BwCShBcmJlaXRza29waWUpCkBAIC0zNSw2 ICszNSwyNCBAQAogI2luY2x1ZGUgPGdsaWIuaD4KIAogZXh0ZXJuICJDIiB7CitnYm9vbGVhbiB3 ZWJraXRfaGFzX2RhdGFiYXNlKHZvaWQpCit7CisjaWYgRU5BQkxFKERBVEFCQVNFKQorICAgIHJl dHVybiBUUlVFOworI2Vsc2UKKyAgICByZXR1cm4gRkFMU0U7CisjZW5kaWYKK30KKwordm9pZCB3 ZWJraXRfc2V0X2RhdGFiYXNlX3BhdGgoY29uc3QgZ2NoYXIqIGRhdGFiYXNlUGF0aCkKK3sKKyNp ZiBFTkFCTEUoREFUQUJBU0UpCisgICAgV2ViQ29yZTo6RGF0YWJhc2VUcmFja2VyOjp0cmFja2Vy KCkuc2V0RGF0YWJhc2VQYXRoKGRhdGFiYXNlUGF0aCk7CisjZWxzZQorICAgIGdfY3JpdGljYWwo IlRoZSBkYXRhYmFzZSBpcyBub3QgYXZhaWxhYmxlIGluIHRoaXMgYnVpbGQuIik7CisjZW5kaWYK K30KKwogdm9pZCB3ZWJraXRfaW5pdCh2b2lkKQogewogICAgIFdlYkNvcmU6OkluaXRpYWxpemVM b2dnaW5nQ2hhbm5lbHNJZk5lY2Vzc2FyeSgpOwpAQCAtNDIsMTAgKzYwLDkgQEAKICAgICBXZWJD b3JlOjppbml0aWFsaXplVGhyZWFkaW5nKCk7CiAKICNpZiBFTkFCTEUoREFUQUJBU0UpCi0gICAg Ly8gRklYTUU6IEl0IHNob3VsZCBiZSBwb3NzaWJsZSBmb3IgY2xpZW50IGFwcGxpY2F0aW9ucyB0 byBvdmVycmlkZSB0aGlzIGRlZmF1bHQgbG9jYXRpb24KLSAgICBnY2hhciogZGF0YWJhc2VEaXJl Y3RvcnkgPSBnX2J1aWxkX2ZpbGVuYW1lKGdfZ2V0X3VzZXJfZGF0YV9kaXIoKSwgIndlYmtpdCIs ICJkYXRhYmFzZXMiLCBOVUxMKTsKLSAgICBXZWJDb3JlOjpEYXRhYmFzZVRyYWNrZXI6OnRyYWNr ZXIoKS5zZXREYXRhYmFzZVBhdGgoZGF0YWJhc2VEaXJlY3RvcnkpOwotICAgIGdfZnJlZShkYXRh YmFzZURpcmVjdG9yeSk7CisgICAgZ2NoYXIqIGRhdGFiYXNlUGF0aCA9IGdfYnVpbGRfZmlsZW5h bWUoZ19nZXRfdXNlcl9kYXRhX2RpcigpLCAid2Via2l0IiwgImRhdGFiYXNlcyIsIE5VTEwpOwor ICAgIHdlYmtpdF9zZXRfZGF0YWJhc2VfcGF0aChkYXRhYmFzZVBhdGgpOworICAgIGdfZnJlZShk YXRhYmFzZVBhdGgpOwogI2VuZGlmCiB9CiB9CkluZGV4OiBXZWJLaXQvZ3RrL0FwaS93ZWJraXRn dGtnbG9iYWwuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJLaXQvZ3RrL0FwaS93ZWJraXRndGtnbG9iYWwu aAkoUmV2aXNpb24gMjcwNTIpCisrKyBXZWJLaXQvZ3RrL0FwaS93ZWJraXRndGtnbG9iYWwuaAko QXJiZWl0c2tvcGllKQpAQCAtMzMsNyArMzMsMTMgQEAKIAogR19CRUdJTl9ERUNMUwogCitXRUJL SVRfQVBJIGdib29sZWFuCit3ZWJraXRfaGFzX2RhdGFiYXNlICh2b2lkKTsKKwogV0VCS0lUX0FQ SSB2b2lkCit3ZWJraXRfc2V0X2RhdGFiYXNlX3BhdGggKGNvbnN0IGdjaGFyKik7CisKK1dFQktJ VF9BUEkgdm9pZAogd2Via2l0X2luaXQgKHZvaWQpOwogCiBHX0VORF9ERUNMUwo=