[MLO] MLO's cloud sync management of conflicting data
Hello, 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? I really don't like having to step off my train of thoughts and think whether A or B is correct. I really think that technology should be able to that for me because other tools already do that. Am I oversimplifying something? thanks -- 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/-/ukwymTlkkgwJ. 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.
RE: [MLO] MLO's cloud sync management of conflicting data
Hi, Kitus. As you mention, it would be great if sync conflicts could be figured out and resolved by the software. I guess the issue would be, how far this could go. I don't think it could be 100%. Suppose I update a task correctly on one platform and make a mistaken update on the other. How would the software know which one I meant? The later one would not necessarily be better. There can also be some very complex situations where repeating tasks are involved. For example, on one platform I might have an update made today to a daily task that was due yesterday, while on another platform I have an update made yesterday to a copy of the task due today. Which one is considered more recent? I have worked with several different automated sync mechanisms over the years, and if one happens to resolve the conflicts the way I would have resolved them manually, then I'm happy. But if it picks the wrong version to keep, the user now faces a much more difficult job finding and undoing the erroneous sync before redoing the sync manually. Most of the automated syncs I have worked with have fallen somewhere between annoying and infuriating. I think the worst was Intellisynch. You mention "other tools" that do it - which ones do you think get it really right?? -Dwight From: mylifeorganized@googlegroups.com [mailto:mylifeorganized@googlegroups.com] On Behalf Of kitus Sent: Wednesday, October 17, 2012 10:54 AM To: mylifeorganized@googlegroups.com Subject: [MLO] MLO's cloud sync management of conflicting data Hello, 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? I really don't like having to step off my train of thoughts and think whether A or B is correct. I really think that technology should be able to that for me because other tools already do that. Am I oversimplifying something? thanks -- 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/-/ukwymTlkkgwJ. 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.
RE: [MLO] MLO's cloud sync management of conflicting data
Hello Dwight, I can’t speak for certain as I’m not actively using it as my main GTD application, but it seems to me as if Wunderlist, Producteev, or other GTD tools, managed to implement a robust sync. Don’t get me wrong, it’s just a humble opinion from someone that has just taken them for a spin and has not actively used them. I just feel annoying two things: - Manually syncing on all my devices (this is very very annyoing) - Having to spend time on deciding which of the changes is the right one when I sit back on my desktop if I forget to sync I’m afraid I don’t have a clever solution though. Just wanted to share with the group my thoughts on this. Thanks for you response. It sounds pretty reasonable all that you say. Marc De: mylifeorganized@googlegroups.com [mailto:mylifeorganized@googlegroups.com] En nom de m...@grantsmiths.org Enviat: dijous, 18 / octubre / 2012 04:56 Per a: mylifeorganized@googlegroups.com Tema: RE: [MLO] MLO's cloud sync management of conflicting data Hi, Kitus. As you mention, it would be great if sync conflicts could be figured out and resolved by the software. I guess the issue would be, how far this could go. I don’t think it could be 100%. Suppose I update a task correctly on one platform and make a mistaken update on the other. How would the software know which one I meant? The later one would not necessarily be better. There can also be some very complex situations where repeating tasks are involved. For example, on one platform I might have an update made today to a daily task that was due yesterday, while on another platform I have an update made yesterday to a copy of the task due today. Which one is considered more recent? I have worked with several different automated sync mechanisms over the years, and if one happens to resolve the conflicts the way I would have resolved them manually, then I’m happy. But if it picks the wrong version to keep, the user now faces a much more difficult job finding and undoing the erroneous sync before redoing the sync manually. Most of the automated syncs I have worked with have fallen somewhere between annoying and infuriating. I think the worst was Intellisynch. You mention “other tools” that do it – which ones do you think get it really right?? -Dwight From: mylifeorganized@googlegroups.com [mailto:mylifeorganized@googlegroups.com] On Behalf Of kitus Sent: Wednesday, October 17, 2012 10:54 AM To: mylifeorganized@googlegroups.com Subject: [MLO] MLO's cloud sync management of conflicting data Hello, 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? I really don't like having to step off my train of thoughts and think whether A or B is correct. I really think that technology should be able to that for me because other tools already do that. Am I oversimplifying something? thanks -- 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/-/ukwymTlkkgwJ. 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.
Re: [MLO] MLO's cloud sync management of conflicting data
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 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í" > 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 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. smime.p7s Description: S/MIME cryptographic signature
Re: [MLO] MLO's cloud sync management of conflicting data
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í" 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 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í" > 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 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.
RE: [MLO] MLO's cloud sync management of conflicting data
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í" 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 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í" 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 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@google
RE: [MLO] MLO's cloud sync management of conflicting data
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í" 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 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.
Re: [MLO] MLO's cloud sync management of conflicting data
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, 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í" > 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 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
Re: [MLO] MLO's cloud sync management of conflicting data
I may have been unclear, I am not proposing that latest transmission time
wins. I agree with you that transmission time alone would give bad results.
Specifically I am proposing an adjusted timestamp which is {client's local
time of edit} minus {client's local time of transmission} plus {server's
local time of receipt} minus {estimated network latency}. I believe that
the adjusted timestamp provides a viable basis for identifying the latest
version of an event. However as noted in a different post, I do not believe
that simple timestamp comparison is adequate for resolving sync conflicts.
Your example with the airplane raises the question of whether the plane
changed time zones. If one device (but not both) has its local time reset
to reflect time zone changes and the reset happened between the edit and
the transmission, my scheme fails.
On Sunday, October 28, 2012 9:29:21 PM UTC-4, Trish P wrote:
>
> 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 )
>
>
--
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/-/5rLHHl_s6pEJ.
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.
Re: [MLO] MLO's cloud sync management of conflicting data
/note: I submitted this by email and it went out to the list be email but did not appear on the server. So I am posting it directly to the server. If you are seeing this email for the second time my sincere apologies and please do not waste your time reading it again./ 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 Thursday, so I complete it twice and now it shows Thursday with a timestamp of Tuesday. For whatever reason I do not complete a sync. On Wednesday on my desktop I see the task, remember that I do not want to deal with it today and mark it complete which leaves it with a due date of Wednesday and a timestamp of Wednesday. Now I sync both platforms. In my opinion, the task due Thursday is the more up-to-date task even though it has the older timestamp. Timestamp-based automated conflict resolution would result in a Wednesday due date which I think is wrong. *You are both right.* Some task has to wait until the next full moon. On my phone I look up the date of the next full moon and enter it to the task. For whatever reason I do not sync right away. Ten minutes later on the desktop I remember that I should change the task’s context to @waiting and do so. Now I sync both platforms. Timestamp processing will pick one change to discard but I want to keep both. The manual conflict resolution window will show me both changes and ask me which one to discard, I will recognize the effort and re-enter the discarded but needed change. Timestamp-driven processing will lose this change. *Trickle down.* The general point is that tasks are not free-standing. There are status changes based on the relationships between tasks and timestamp processing will miss this by looking at the tasks individually. Example, I have a daily task with four subtasks. If all subtasks complete the parent is automatically marked completed by MLO. If the parent is marked complete any uncompleted subtasks are marked completed by MLO. The children inherit their start and due dates from the parent. On Monday, everything is marked for Monday, incomplete. At 10am for whatever reason I use my phone to mark the parent completed, which rolls the parent and all children to Tuesday, all uncompleted, all with a 10am timestamp. This is done to essentially say “I am skipping this today.” For whatever reason I do not sync at this time. At noon on the desktop the parent and children all point to Monday. I find that I have actually completed two of them and mark them complete. The four child tasks on the desktop all point to Monday with two completed with a noon timestamp and two incomplete with a prior day timestamp. The parent on the desktop points to Monday with a prior day timestamp and is uncompleted. Now I sync. The parent is set to Tuesday based on the 10am timestamp. Two children are set to completed based on a noon timestamp and two to uncompleted based on a 10am timestamp; all four children are set to Tuesday dates by inheritance from the parent. The result is that I have two tasks shown as having been completed on Tuesday even though it is only Monday and I have not yet started work on Tuesday’s tasks. Each of these anomalies can be addressed by writing sufficiently complex code, but then other anomalies are identified and more code needs to be written. By the end of the task, the code gets to be big, clumsy and difficult to maintain. Unless smarter people have come up with better solutions since the last time I looked. -Dwight On Sunday, October 28, 2012 8:19:11 PM UTC-4, Dwight Arthur wrote: > > 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 > > -- 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/-/mp6DU-Jnih4J. 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.
