Hi Trish and Marc. I will admit that I have done coding in my life. This clock issue has been solved. It’s not necessary that any of the clocks in the system be set correctly, only that none of them are gaining or losing time quickly enough to be noticeable. What happens is that whenever a client system talks to the server it reports its own local time at the time of transmission. The server calculates the difference in time between the time a message is sent by a client and when its seen by a server. This time is called the delta. Then, when a client says a transaction happened at a particular local time, the server can subtract the delta is has calculated for that particular server to produce an estimate of the server’s local time at the time of the transaction. For global networks with heterogeneous speeds, a latency factor can be calculated by sending a message to the client that’s immediately returned, measuring the time from transmission to receipt, and dividing by 2. If this latency measure is subtracted from the delta, it produces a latency-adjusted delta which reduces or eliminates the advantage that usually falls to those clients connected by the fastest network connections.
When two events are nearly simultaneous and where significant benefit falls to the one judged to be first, this scheme will not hold up. MLO synch probably falls into the category where people are willing to lose a near-tie which make this approach feasible. This approach is nevertheless subject to gross failure in the event that and party adjusts a clock’s value between the time when a timestamp is taken and when it’s evaluated. For example, if an event happens one second before Daylight Savings Time starts and the client reports it to the server two seconds later, under Daylight Savings Time, the server’s calculation will be one hour off. That said, I do not believe timestamps produce a reliable answer even when the time itself is reliable and accurate. I will document that in a separate message. -Dwight On: Sunday, October 28, 2012 2:15 PM, Trish Putnam wrote: The problem would be with guaranteeing that all clocks had a valid and reliable time to a very high degree of accuracy. One thing that could be done, perhaps, is to provide a setting to allow the user to decide whether to trust timestamps. If yes, then the computer handles conflict resolution automatically. If no, behavior stays as it is today. On Oct 28, 2012 10:00 AM, "Marc García Martí" <marc.garcia.ma...@gmail.com> wrote: I said I'm no software developer, but if the app itself checked current clock locally before uploading content, it could attach the current time to the information. That way, assuming all the devices have a valid and reliable time, the cloud itself could figure things out automatically. Thanks On Oct 28, 2012, at 3:58 PM, Trish Putnam <trish.put...@gmail.com> wrote: I don't think you could assume a common clock, since that would require all the devices to be online at the time of change to access the clock. 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.
