Basing the timestamp on the time of transmission requires reliance on the false assumption that all devices making the change are online and transmitting all the time.
For example: I'm on a plane with my phone and my tablet. Both are properly offline for the flight. I make a change to my data on my tablet, and put it away for the remainder of the flight. Meanwhile, I play Angry Birds on my phone for a while, then realize that my change wasn't quite right, and pop open MLO on my phone to make an additional change to the same data. The phone, then, should be the winner in a conflict. However, my phone connects first when I get off the plane, and transmits my data - per the transmission time, it was first. My tablet transmits ITS data moments later when I turn my tablet back on, and per the transmission timestamp, it is actually the conflict winner as the most recent change, even though the change was actually made later on my phone. Transmission time should NEVER resolve the conflict - it's irrelevant to the actual time of data change. Conflict resolution of that sort should be based on the time the change is saved on the device, with the caveat that the concept of delta and adjusted timestamp is still relevant. (For what it's worth, I have worked in the software industry for about 14 years, so I'm not a complete rookie, either :D ) On Sun, Oct 28, 2012 at 5:50 PM, <m...@grantsmiths.org> wrote: > Hi, Marc. There are a number of scenarios in which relying on the latest > timestamp does not work. Three that come quickly to mind are (1) Today’s > changes to yesterday’s task, (2) you are both right, and (3) trickle down. > **** > > ** ** > > Today’s changes to yesterday’s task**** > > I have a task that repeats daily. Monday I complete the task and now it > shows Tuesday. On Tuesday on my phone I realize I will not be getting to > this task until Wednesday, so I complete it twice and now it shows Thursday > **** > > ** ** > > On Oct 28, 2012 6:12 AM, "Marc García Martí" <marc.garcia.ma...@gmail.com> > wrote:**** > > Hello,**** > > ** ** > > I'm no software developer, but I imagine that if the different clients, or > sources of information, shared a common clock, and the cloud server checked > that clock, the system itself could resolve the conflicts. just my opinion > of course.**** > > ** ** > > Thanks**** > > ** ** > > On Oct 28, 2012, at 2:44 AM, Dwight Arthur <m...@grantsmiths.org> wrote:*** > * > > > > **** > > I've been thinking long and hard about this and I think I've been coming > at it from the wrong angle. I have been studying, when there's a conflict, > how can an algorithm resolve it. The better question, I think, is whether > the conflict can be avoided. The only way to make a conflict is to update a > task on one device and leave that change unsynched for long enough for the > user to get to another device and make a conflicting update. If every > platform synched soon after a local change and also soon after a remote > change has been synched, provided that the sum of the two "soon"s is less > than the time it takes to go to a new device and enter a change, then there > will be no conflict. (Except in abnormal circumstances such as blackout.) > > On Wednesday, October 17, 2012 10:53:50 AM UTC-4, kitus wrote:**** > > <...> I was wondering, can't the cloudsync handle conflicting data > autonomously? why do I have to be prompted when the same action has been > updated from different devices? <...>**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "MyLifeOrganized" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/mylifeorganized/-/Ust4cQY5HccJ. > To post to this group, send email to mylifeorganized@googlegroups.com. > To unsubscribe from this group, send email to > mylifeorganized+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mylifeorganized?hl=en.**** > > ** ** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "MyLifeOrganized" group. > To post to this group, send email to mylifeorganized@googlegroups.com. > To unsubscribe from this group, send email to > mylifeorganized+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mylifeorganized?hl=en.**** > > ** ** > > -- > You received this message because you are subscribed to the Google Groups > "MyLifeOrganized" group. > To post to this group, send email to mylifeorganized@googlegroups.com. > To unsubscribe from this group, send email to > mylifeorganized+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mylifeorganized?hl=en. > -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to mylifeorganized@googlegroups.com. To unsubscribe from this group, send email to mylifeorganized+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
