u1db-discuss team mailing list archive

[eric casteleijn <eric.casteleijn@xxxxxxxxxxxxx>]

On Tue, 29 Nov 2011 09:52:50 +0000, Stuart Langridge <stuart.langridge@xxxxxxxxxxxxx> wrote:
> One of the things that isn't clear at the moment is whether u1db should
> do extra work to enable shared databases. By shared, I mean a u1db
> database being accessed by more than one application at once.
> 
> To be clear, this question is not about the backend being able to handle
> being opened by multiple applications. This is about app developers.
> (And only app developers on platforms where a file *can* be shared;
> Windows, Ubuntu, OS X, possibly Android; not the server-side web, iOS,
> in-browser.)
> 
> The obvious problem for app devs if another application might
> simultaneously edit their database is that the data will change and they
> won't know. So, if we encourage the idea of multiple apps using the same
> database, we'll need to come up with a way that apps can know that the
> data has changed. At the moment we have whats_changed(generation), but
> apps don't know when to call that... so they'll have to poll, which is
> bad.
> 
> Actual apps using a database simultaneously is likely to be fairly rare,
> but one thing that has been talked about is a "sync daemon"; on desktop
> environments, if you save a u1db in a particular location then the sync
> daemon would sync that u1db with Ubuntu One for you. This process has
> two big advantages: the first is that apps don't have to handle the sync
> process themselves, and the second is that apps don't need to handle
> authentication to Ubuntu One themselves. This sync daemon would
> obviously be an app accessing the databases; if it existed, apps would
> have to have some way to know that the data had changed.
> 
> 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.

> So... do we have a sync daemon and support multiple apps? Or do we avoid
> this problem by not dealing with it, at the expense of making every app
> developer handle authentication and syncing themselves?

I think there should be libraries for doing auth & sync with U1 for
each language. 

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