[jp] Goodbye, and thanks for all
stuart at xnet.com
Tue Jul 16 16:04:05 EDT 2013
(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.
More information about the Jpilot