[Unison-hackers] unison and inotify principle

[Sylvain Le Gall]

Hello,

On 04-06-2008, Benjamin Pierce <bcpierce at cis.upenn.edu> wrote:
> P.S.  In case you want to help move this bit of design forward, I  
> wanted to mention that version 2.28 of Unison actually includes a  
> very simple version of this functionality.  Here is the commit log  
> entry...
>
>
> * Very preliminary support for triggering Unison from an external
>    filesystem-watching utility.  The current implementation is very
>    simple, not efficient, and almost completely untested.  Not ready
>    for real users.  But if someone wants to help me improve it (e.g.,
>    by writing a filesystem watcher for your favorite OS), please let
>    me know.
>
>    On the Unison side, the new behavior is incredibly simple:
>      - use the text UI
>      - start Unison with the command-line flag "-repeat FOO",
>        where FOO is name of a file where Unison should look
>        for notifications of changes
>      - when it starts up, Unison will read the whole contents
>        of this file (on both hosts), which should be a
>        newline-separated list of paths (relative to the root
>        of the synchronization) and synchronize just these paths,
>        as if it had been started with the "-path=xxx" option for
>        each one of them
>      - when it finishes, it will sleep for a few seconds and then
>        examine the watchfile again; if anything has been added, it
>        will read the new paths, synchronize them, and go back to
>        sleep
>      - that's it!
>
>    To use this to drive Unison "incrementally," just start it in
>    this mode and start up a tool (on each host) to watch for
>    new changes to the filesystem and append the appropriate paths
>    to the watchfile.  Hopefully such tools should not be too hard
>    to write.
>

I am a very humble user who just want to comment on this design (take
all of this conditionaly -- if you feel this is just silly, forget about
it).

I don't like the idea of the "file which should be a newline-separated
list of paths (relative to the root of the synchronization)". 

My idea is the following: 
- use "-repeat FOO" but FOO is a program 
- FOO read file scanned by unison on stdin
- if FOO detects a change in a file scanned by UNISON, it writes it on
  stdout

In this design, unison has just to send absolute filename name to FOO
and wait for FOO to write any notification.

Moreover, you will just have to use "Unix.open_process" which is one of
the fully portable function (at least Linux/Windows) of the Unix module.

Regards
Sylvain Le Gall

ps: the solution is less simple than the other but external notification
program is easier to write and notification is more efficient.