I cannot answer all of these questions, but here's the bulk of them. On Aug 10, 2013, at 8:07 PM, Mark Finkle <[email protected]> wrote:
> 1. In my early discussions with the old Services team, Sync 2.0 was termed: > (Sync 1.1 + bug fixes) + pluggable Auth. This that a reasonable definition? Yes, plus taking what we'd learned from problems in 1.1 and adding features to make them a bit better in 2.0, and a more robust content-versioning so that future storage-format upgrades would be easier. > 2. Getting Sync 1.1 to work with a new Auth means work. Work on the client as > well as the server. Does starting with Sync 2.0 get us some baseline of > completed Server work? 2.0 server is completed, tested and basically ready to go. I'm sure we'll tweak it based on needed protocol changes, and we might use a different underlying storage layer eventually, but we could theoretically launch it now. Server 1.1 with new auth also just needs dusting off and could be deployed. > 3. I have heard the Android client code was built with Sync 2.0 in mind. Does > that mean we are not in "re-write the world" mode if we decide to move ahead > with Sync 2.0? > 4. I have heard that some Sync 2.0 Javascript client code exists in > mozilla-central and could give us some baseline of completed Desktop client > work. True? Somewhat true? False? My recollection is that gps had written, among other things, a server 2.0 implementation in javascript so that the test suite would be self-contained. I believe that there was some solid work in the client part as well, but I'm not qualified to speak about that. > 5. No client-side work has been done on Sync 1.1 (existing code) since > perhaps the beginning of 2013. There are extensive lists of existing bugs and > no one has been fixing them. The team was disbanded. About a year now, actually. Wow, time flies. > 6. There is a general assumption that the only thing broken with Sync 1.1 is > scalability, which was "fixed" last month (thanks ServerOps), but the long > list of SUMO complaints and the bug lists in #5 tell a different story. There's plenty broken with Sync 1.1, but, ironically, scalability (with appropriate ops babysitting) isn't an issue any more than for any other large-scale system. Sync is evolved Labs code that we've learned what not to do the hard way on many occasions. It was built under assumptions that weren't borne out and to support goals (sharing! arbitrary objects! flat tree structures!) that never came to fruition. Nobody is under the impression that sync is doing anything but limping along right now. Sync 2.0 was the first stab at addressing some of the issues before that was abandoned. > 7. Neither Sync 1.1 or Sync 2.0 support the level of server-side durability > we want moving forward. I assume neither one has an advantage over the other > for getting server-canonical durability. True? More or less. There are two major reasons Sync 1.1 doesn't have durability: * When it launched in early 2009, mysql replication was single-threaded. That thread could not keep up with the write load. We did put in fixes for this - I had a dual-write system going for a bit, but… * Durability is expensive. Essentially you're doubling your requirements. At the time, it was decided that it was an expense not worth paying for in a client-centric system being run on a shoestring budget. In general, I still believe that was the correct decision. The number of people who have been affected by sync-is-not-backup in the last few years is tiny, since, 99% of the time, it effectively has been. Now that we're moving to a server-centric model, though, durability becomes a lot more important. That's mostly just committing the money; there's no technical barrier to either version. > 8. Server side work has already started to stand up the Sync 2.0, so > unbitrotting, auth integration and server durability work can commence. Yeah, we'd need a little bit of unbitrotting, but the remaining work on the server side would be a tiny portion of what needs to be done. > Using Sync 1.1 as a foundation for moving ahead would not be the cheapest > solution. There is work to get the Auth system working with it, and > significant bugs that need to be addressed. Sync 2.0 appears to be an effort > by the Services team (server and client) to address some of Sync 1.1 short > comings and get pluggable Auth working. This seems like what we would need to > do if we started with Sync 1.1 anyway. If we are set on using the existing > Sync codebase to start building Sync.next, we should use Sync 2.0 and not > Sync 1.1 as the foundation. Sync 1.1 takes us to far back in time. Yes. The only reason to use sync1.1 over 2.0 is if we wanted to decouple auth and storage work. In theory, we could add backwards-compatible IdP-auth to sync 1.1 and just improve that part, without addressing any of the aforementioned storage bugs. Any meaningful storage work requires moving to sync 2.0 (along with the associated flag day). Hope this helps, Toby _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
