[haiku-development] Re: Working on Caya and Mail app for GSoC
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 31 Mar 2011 15:01:44 +0200
On 2011-03-31 at 01:06:54 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
wrote:
> On Thu, 31 Mar 2011 11:13:51 +1300, Truls Becken <truls.becken@xxxxxxxxx>
> wrote:
> > On Wed, Mar 30, 2011 at 03:26, Clemens wrote:
> >
> >> are we still taking about mapping local contacts to contacts on the
> >> server?
> >> If yes there is no clean and elegant way to handle this with a userland
> >> server. You always have to watch the filesystem for local changes and
> >> if the
> >> local server is not running you don't know whats going on locally and
> >> its
> >> very difficult to decide what to do on the next sync.
> >
> > My reaction to the above was; isn't this problem solvable? What if it
> > was possible to tell the system that you wanted it to not only deliver
> > live filesystem notifications, but also record the changes until you
> > ack them?
> >
> > When a server starts up, it can pull all the undelivered
> > notifications, solving the issue about not listening 24/7.
> >
>
> yes such a log could solve the problem but it have to be an atomic fs
> operation otherwise you get out of sync when you crash during a file
> operation.
In offline mode a file system would have very similar problems. Besides, I
wouldn't use a log in a server, but an index of the last synchronization
state (per remote service). Comparing it with the local and the remote
states yields the local and remote changes since the last synchronization.
BTW, a feature lost with a FS is Tracker undo/redo. Unless one also
implements a trash directory that is.
Another point speaking against a FS is that in case of conflicting (local
and remote or different remote) changes one needs a GUI for solving them,
which a FS cannot provide.
CU, Ingo
Other related posts:
