GNOME Bugzilla – Bug 151803
Add a way to synchronise bookmarks and passwords using a remote server
Last modified: 2017-01-11 09:57:19 UTC
This is similar to Netscape's roaming profile setup. Here, the feature could use files on a remote, gnome-vfs-accessed, server. Ultimately, the feature would be able to synchronise bookmarks and passwords (cookies?), including removals from 2 or more machines.
Mass reassigning of Epiphany bugs to epiphany-maint@b.g.o
I think basic support would be easy, you'll just have to write gnome-vfs input/output callbacks for libxml2. However, there are some problems with this: - what happens when, on startup, the remote file is unavailable (server down)? - same on shutdown and whenever we're saving the bookmarks file (which is on a timeout after any changes) Do you then startup without bookmarks (which gives problems with bookmarks in toolbars), or without bookmarks, and load when they become available? That would need some re-architecturing the bookmarks editor and bookmarks bar. Would you then write to a temp file on disk, and push to the server later? What happens then when we next load from the server when you've accessed your bookmarks from another computer; do we merge changes/throw away one set of changes?
* If you cannot connect to to bookmarks file server, the bookmarks should probably just be displayed whenever they become available (in fact ephy shouldn't wait to connect to the bms server to start since this could be slow and make startup seem sluggish). * As you say, ephy should create a local copy of the bms file if the server later becomes unavailable. In fact, ephy should prolly make a copy of the file from the server when it first connects so. Then, if you close ephy and upon restart you can't connect to the bms server, ephy can fall back to the local copy. Any changes you might make when using the local fall back should then be merged back to the server when it next becomes available. PS: Link ref where this is briefly mentioned: http://mail.gnome.org/archives/epiphany-list/2004-November/msg00048.html
Example I/O callbacks: http://xmlsoft.org/examples/index.html#InputOutput and http://xmlsoft.org/xmlio.html#Example2
Created attachment 38753 [details] io-gnomevfs.c Reading from libxml2 using gnome-vfs2
Created attachment 38760 [details] io-gnomevfs2.c Writing to gnome-vfs using libxml2
Christian, is the hold-up on this to have a list of what to do in error cases?
Yes, the behaviour in error cases need to be defined first (comment 2 and comment 3). Allowing delayed load of bookmarks as suggested in comment 3 would require major restructuring (the bookmarks are needed on startup for the location entry completion and the bookmarks toolbar); but this may be in scope of Peter Harvey's bookmarks work (not sure if he's still working on it). Creating a local copy to work with if the server is unavailable is of course unproblematic; the problem is what to do when the server becomes available again (merge, conflicts).
Is this still at the order of the day ? Do the harves' patch solved the issue of async bookmarks loading ? Concerning the local copy problem: 1) Download periodically remote bookmark file 2) Save periodically the locally modified bookmark file. 3) if the file has been modified both on remote and local in a conflicting manner (ie. not just adding or removing a bookmark, but adjusting title or url, for example), the remote file is left unmodified, and the local modified bookmark is copied from the remote file to the local bookmarks. That way, you don't loose the modifications, but you still have an easy way out in case of conflicts. Conflicts will not happen often, and if it happen you will have two similar entries in the bookmark list, one copied from the localy modified file, the other modified remotely. The user can then resolve the conflict itself either by removing it, or by removing the local copy.
Google have released a Firefox extension that does bookmarks synchronisation and more, not sure whether it's open-sourced at all. http://www.google.com/tools/firefox/browsersync/index.html
I feel it's probably worth mentioning here that the new version of Tomboy has a synchronization feature. Hope that somehow helps in developing this Epiphany plugin.
We'll want to sync as much as we can between Epiphany instances, surely the user's history, possibly website data, and maybe even the entire WebKitWebViewSessionState for each tab (though that might be too much to reasonably transmit over the network). Obviously everything would need to be securely encrypted. We will want limited sync support for some mobile browser, as well. This bug would require research to determine whether to use OwnCloud or Firefox Sync. Mozilla allows us to use the same sync server as used by Firefox, which would probably be best as OwnCloud sync would probably not be accessible to normal folks (who don't understand what servers are). Although the OwnCloud developers are interested in GNOME and would likely be helpful were we to pick OwnCloud; that would also simplify authentication as it would be handled by gnome-online-accounts.
Hi, the bookmarks code has been rewritten from scratch. When you have a convenient opportunity to test the new version of the code (which will be present in Epiphany 3.23.1) please check to see if your issue is still a problem, and reply here. Thanks!
Fairly certain this wasn't implemented.
Actually bookmarks sync via Firefox Sync should be landing very soon, certainly before the next release and possibly even today. Hence I'm going to (slightly-optimistically) mark this as fixed. Passwords a totally separate issue and really needs to be a separate bug. We plan to implement it anyway, but maybe a lower-priority than History.