[jp] Goodbye, and thanks for all
jack at 3kitty.org
Tue Jul 16 18:12:55 EDT 2013
Time-stamping is not good enough. In my example, both parties changed
the event to be 1-1/2 hours, so no matter who wins the result will be
1-1/2. But the correct value is 2 hours.
In database lingo, this gets into "Distributed Transaction Processing" -
a Hard part of that Real Hard Problem. However, this is pretty much a
solved problem. That's what databases do. The question is when and if
that technology will make it to PDAs and such. Meanwhile, as you say,
we have to be careful and follow some rules.
A "change history" can help. But apps also have to be designed with
knowledge of the distributed nature. For example, a "change" primitive
which allows you to "change the beginning and end times" of an
appointment isn't able to solve the scenario I outlined and always get
the right answer. A different primitive, to "change the duration by X
minutes" of an appointment, could get the right answer. I think.
Maybe. It's a hard problem...
On 07/16/2013 01:04 PM, stuart wrote:
> (we should really start a new thread)
> Am I the only one thinking this problem has already be (partially)
> solved in GIT?
> 30K view: All changes are time stamped. All devices are
> synchronized. All changes are considered in their actual temporal
> order. Not in the order the devices were synchronized. So, who ever
> made the last change wins. The assumption is the person making the
> later change knows more about the situation. Not always true. But you
> have to make some rules. If you want to make it perfect, then you
> need to add change history to each event and make that available to
> all devices upon each synchronization.
> On 7/16/2013 2:37 PM, Jack Haverty wrote:
>> I worked at Oracle for 8 years, and one thing I learned is that
>> distributed databases are Real Hard Problems, especially when the
>> players can be "offline".
>> Consider some kind of calendar server, "syncing" with a couple of
>> PDAs occasionally. Perhaps you and your spouse both have some kind
>> of smartphone and you use them to coordinate your schedules.
>> You enter an appointment - say to go to a shopping mall, and allocate
>> an hour to shop.
>> You later decide you need more time, so you can go to a another
>> nearby store and pick up something. So you use your PDA to change
>> the appointment to add a half-hour.
>> Independently, your spouse remembers another errand in that vicinity,
>> and also uses a PDA to change the appointment to allow more time for
>> that, also adding a half-hour to the appointment.
>> Depending on when you and your spouse "sync" with the server, the
>> server will also change the appointment to reflect the changes it has
>> been told about.
>> The question is -- when the dust settles, how long is the appointment
>> set to be? Depends on who syncs when. I haven't looked at iCal or
>> DAVICal, but in systems I have looked at, admittedly years ago, a
>> likely answer was that the server would have concluded the
>> appointment should be 1-1/2 hours long. But you actually need two
>> hours to do all your errands. You can imagine lots of other similar
>> scenarios where the end result is the wrong answer in the server
>> database. Any time when you have more than one device syncing to the
>> same server you're potentially in trouble. Distributed databases are
>> Real Hard Problems...
>> What happens in this experiment when using iCal, DAVICal, etc...? It
>> would be great to hear that they've solved this kind of problem.
>> The "folder/file sync" is not a solution to this problem either. You
>> still have to be careful in how you use it. But I've found that it's
>> sufficient, if a little unwieldy, as an interim solution until
>> someone creates the apps/servers that do it "right". My ancient
>> Palm just wasn't going to last much longer. so, for now, the
>> file/folder scheme lets me use my Android phone and tablet, as long
>> as I'm careful about the syncing behavior.
>> On 07/16/2013 11:08 AM, Johan Vromans wrote:
>>> "James E. LaBarre" <j.e.labarre at gmail.com> writes:
>>>> The problem with anything like Foldersync is it's a file-level sync;
>>>> PalmOS/jpilot operates on a record-level sync. Not much good if you
>>>> want to use a system offline, then replicate the changes later.
>>> That's why for agenda and contacts it is much better to use an iCal
>>> server like DAViCal. These work on a per-appointment (contact) basis.
>>> -- Johan
>>> Public archival of this list without permission is prohibited.
>> Public archival of this list without permission is prohibited.
> Public archival of this list without permission is prohibited.
More information about the Jpilot