> > I also tend to think that the current Firefox Sync solution could be the > way to go for this kind of data, at least initially. We can start working > on making Firefox OS use the existing Firefox Sync platform for browser > related data like history, bookmarks, form autocomplete data, > requestAutocomplete data, passwords, etc. We can expose a system only API > to content to allow Gaia to use the existing infrastructure. >
Interop with other Firefoxen definitely makes sense. Two words of warning: 1. As I cautioned in Bug 824026, I think the desktop Sync codebase is probably not reusable in this context, so you would have to do some non-trivial work. 2. Adding new datatypes to Sync isn't a quick and easy affair, and we are definitely moving in the direction of deploying new special-purpose FxA-attached services instead of stitching new kinds of data into the legacy Sync system. Just like Calendar and Email, we can use 3rd party services to sync data > with (i.e. Google, Outlook, Facebook (maybe not anymore)), but we still > need a solution for locally generated content like new contacts or merged > contacts. There has been some previous efforts to do this for contacts in > the past [2]. > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=976837 > And Bug 1019787 (and Bug 859306, and …). Related to this effort: https://etherpad.mozilla.org/firefoxos-sync > One of the ideas that came from the v3 ideation process was task > continuation. Specifically, the example of an instant messaging app that > users could use from any device (desktop, mobile) to send and receive > messages (including SMS or MMS if a phone number or a RIL enabled device is > "connected"). I can start a conversation on my phone and finish it on my > laptop (like Whatsapp does now). This idea is even more attractive if you > add WebRTC to the equation. > Definitely try to sync up with what desktop and mobile UX has been thinking in this area, particularly Darrin and Madhava. I would say that installed apps synchronization should also be part of the > browser related data that I believe that could be initially managed by > Firefox Sync. I would love to be able to have the FxOS Music app running on > my desktop via WebRT just by enabling Firefox Sync on my browser or the > Telegram app being installed on my laptop when I install it on my FxOS > device, for example. > Amusingly, we built something called AITC (Apps In The Cloud) about 3 years ago. It was decommissioned and removed from the tree a little later. > * Arbitrary data - Handle data syncing for arbitrary web content > > > This is where things are more interesting. IMHO the hardest part here is > to create the more generic possible solution that could enable 3rd party > developers to use our sync platform. > Yeah, this is a big challenge. Dropbox's structured data API is a pretty good general solution to this problem (with some drawbacks, of course). > 1. At Mozilla we are in the unique position to focus on providing the user > with the choices that they want over attempting to leverage features to get > users locked in to our platform, and I think we should focus on that. Sync > contacts with Google, Photos with Dropbox, SMS's with our own storage > services etc. > > > Yes! User choice is key. > Thus far this is not something we've put a ton of effort into with FxA. In theory it's possible to attach arbitrary services to your FxA, implementing various syncing needs. See https://wiki.mozilla.org/User_Services/Meta for one way to do this. In practice we have not done so, and each client hard-codes its service URLs. I'd like to see us move in the direction of more flexibility here. > > 2. The characteristics of those sync uses cases (that were not exhaustive) > are very different, I dont think we will have a 'data sync solution', some > of the use cases may converge (App sync and SMS), however syncing files > with drop box looks and acts hugely different from syncing history in the > browser and I dont think we can try to force a single solution for both > cases. > > One thing we've learned from Firefox Sync is that it's almost impossible to make the right tradeoffs for all of these datatypes. I generally advise "reuse, don't combine" — make separate services that might, if convenient, share an implementation. The current Reading List service, for instance, is quite generic and could be repurposed for storing contacts… but I wouldn't suggest that we make the same service handle both RL and contacts!
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
