> > > There is so much wrong with your analysis that I don't know where to > > > start. > > > Fortunately, its also so far out of scope that I don't have to. Your > > > perspective is appreciated, but we have made certain decisions at this > > > point, and we will not revisit them. Until we get different guidance, the > > > use cases are what they are, and the goal of getting an MVP to market is > > > set. If you disagree with that strategy, we will have to agree to > > > disagree, > > > but I will still need your full support with implementing it. If you > > > would > > > like to help with resolving remaining technical detail issues, please do > > > so > > > by listing concrete, relevant, realistic use cases. General statements of > > > disagreement are not useful. > > >
> > Be careful falling back on the high-level MVP as a crutch to avoid making > > hard decisions. The MVP does not contain low level details on consistency > > and conflict resolution. It shouldn't. The MVP does have a section on > > "Performance and Stability" and that section does make some statements > > about > > users "expecting zero data loss." > > Zero data loss is not zero data loss. A zero data loss service cannot be > built. Such technology simply doesn't exist. We need enough 9s to appear to > the user to not lose data. If data loss is so rare that other events such as > "meteor strike" are more frequent, there is no point in engineering for > those cases. Lets get concrete cases, we can fairly easily estimate > frequency, and then we know what we actually have to handle. I actually agree with you. I just saw the discussion leaning towards the opposite end of the spectrum and thought I'd try to back us back to the center.
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
