Robin and I spent an hour or so today talking through how our bookmark UI should end up, and how the complexity introduced by Sync can be integrated or masked in a way that doesn't baffle users.
(For example: showing two Mobile Bookmarks folders is confusing, but is a natural result of some of our fallback behavior. Allowing the user to delete some bookmarks but not others is confusing. And so on.) We think we have a reasonable handle on how to move forward; as I understand it, this is at the front of Robin's queue, and I'm giving her all the support I can. A couple of notes from me inline: * Even if the initial download looks good, your data may get inconsistent > at some later stage at which point the bookmarks will become read-only. > That's not currently the case in the code, but we've been designing under the assumption that we'll need to model and surface this intermediate I-did-sync-but-now-I-can't state. 3. We automatically enable it when we discover your data is in good shape > After we do the initial bookmark sync, we actually know if your data is > bad or not. If it is good then we can enable bi-directional bookmark sync. > If it is bad then we fall back to read-only. However, since data can also > become corrupt at a later time, we still need to deal with that. But, we > can explain to the user why this happened. We can provide instructions > (SUMO article) on how to re-upload your sync data with Desktop. This is roughly the direction that the existing code (and Robin's mocks) move in: if we're able to sync you, we will; if your stuff later breaks, we'll try to tell you how to dig your way out, and once broken we won't let you dig yourself deeper (e.g., by moving things around or deleting folders). Messaging this without sounding really amateurish is a challenge — "hey, sorry, you need to go turn Sync off and on again on your desktop, and you might want to make a backup first" — but we'll figure something out. There are some cases where the iOS client can ignore certain cases of bad > data. It is not a solution, but this could make the success rate higher. This is a relatively small set, and we'd need to do a little analysis to figure out exactly what's safe. For example, we could try to ignore backpointers from child records, but it's possible that those are more accurate than the child lists in folders; which one is wrong depends on how various desktop bugs behave in the wild, and I haven't studied those deeply yet. My general hunch about this slice is that it's thin enough that it won't make a big dent — too much corruption is about missing records or serious record disagreements. But we'll see. 2. We make the iOS client self-healing > If we detect data inconsistencies we may be able to fix them, and then give > the user to re-upload their data back the server. Lots of complexity here. This is what we tried to do, somewhat blindly, on Android: rather than letting clients diverge (the desktop approach), it tried to reach consistency and then get clients to agree. In retrospect I think this was a bad decision on that platform, because — as with desktop — Android's bookmark sync code is very myopic, so it couldn't make a good judgment call between, say, one leaf record being missing and one critical folder being totally wrong. We didn't realize the extent of the problems with desktop and the Sync protocol, else we'd have taken a more cautious approach. iOS is much more informed, of course, so it might theoretically be possible to do subtree merges to at least get some bidirectional changes working. If all we've done on the device is add some bookmarks to Mobile Bookmarks, then perhaps it's safe to upload those. (But perhaps not!) We can take a broader view of this option, too: "get iOS to fix things any way it can". For example, we might also consider adding channels to allow us to remotely tickle desktop into fixing state — e.g., a command "upload this record if you've got it", or a "missing persons" collection. This allows us to potentially implement smart recovery before desktop can build and ship it themselves. This would require some desktop changes, but they'd be more tractable.
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
