u1db-discuss team mailing list archive

[eric casteleijn <eric.casteleijn@xxxxxxxxxxxxx>]

On Tue, 29 Nov 2011 07:59:46 -0500, eric casteleijn <eric.casteleijn@xxxxxxxxxxxxx> wrote:
> > It is difficult to think of a good way of handling this without either
> > apps polling whats_changed in a background thread or implementations
> > providing some sort of async the-database-has-changed signal. However,
> > async stuff is very implementation-specific, which makes it hard to
> > document this approach, and the Python reference implementation won't
> > contain it (because it is all sync and does not require a mainloop).
> 
> I can't see a way around polling, really, if we want to do this. The
> alternatives are all harder to do, and don't necessarily solve the whole
> problem. If two processes that don't know anything about each other need
> to access the same data store, lock on write and polling for changes
> seems to me the only sane solution. (well signals could work, as you
> say, but polling seems simpler.)
> 
> Every other solution I have though of so far means we lose all of the
> simplicity that make the current design so attractive.

One way of doing this that does not involve implicit polling, would be
to let the user explicitly sync data between applications that care
about the same data (so each app would have their own db,) either in yet
another process that made sure none of them were running, or from within
an application (but then only a one way sync, getting the changes from
the other app, but not sending yours back, so that the other app won't
need polling.)

-- 
eric casteleijn
https://launchpad.net/~thisfred