Re: [Caml-list] File synchronization implementation(s) in OCaml?

[Evgeny Roubinchtein <zhenya1007@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]

Thank you everyone for all the responses and pointers to artefacts and
papers.

Cedric, that is an excellent point; thank you.  My current intended use is
having the user edit file(s) on host A using a text editor, and, when the
user saves a file, having those edits reflected as quickly as possible in
the corresponding file on host B.  So, my primary measure of performance is
the speed of update: I want the time between the events "the user, who runs
the editor on host A, has issued a command to the editor to save the file"
and "the contents of the file the user has just saved on host A and the
corresponding file on host B is identical" to be as low as feasible (there
is a mapping between file paths on hosts A and B).  Sometimes, the user
will create a new file on host A; then the file's contents needs to be put
as quickly as possible into the corresponding location on host B.  One
other consideration is that occasionally   the user may have their text
editor save a number of files in quick (at least in human scale)
succession: for example, the user issues "M-x compile" in Emacs, and Emacs
offers to save all modified buffers before running the compilation: in that
case, the total time to propagate the changes to all modified file(s)
should be as low as possible.  So, to summarize:

1. One-way synchronization is acceptable (I may find out otherwise with
experience, but, for now, I am willing to make that assumption)
2. It is always known which file(s) have been modified.
3. It is probably feasible to plumb through the information about what
part(s) of of a file were modified for each file from the text editor to
the updater, if that helps with the speed of the update.  The editor
usually "knows" what has changed, because it needs to be able to undo the
changes.
4. The relevant metric is the speed of the update.
5. Sometimes changes to more than one file may be saved in quick (human
scale) succession.  The relevant metric is still the speed of update to all
files.

I apologize for the somewhat long-winded description of the metric I care
about.  I do hope that clarifies it.

-- 
Best,
Evgeny ("Zhenya")

On Thu, Feb 8, 2018 at 6:44 AM, Yaron Minsky <yminsky@janestreet.com> wrote:

> Ha! The paper you linked builds off of an old paper I wrote:
>
> http://cis.poly.edu/westlab/papers/ref/practical.pdf
>
> There is in fact a full implementation of the algorithms in this paper
> in OCaml, as part of the SKS system that I wrote many years ago.
>
> https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home
>
> I'm not especially proud of the code, but it does work...
>
> y
>
> On Thu, Feb 8, 2018 at 8:11 AM, Cedric Cellier <rixed@happyleptic.org>
> wrote:
> > -[ Wed, Feb 07, 2018 at 07:05:15PM -0800, Evgeny Roubinchtein ]----
> >> I don't want anything that performs worse than rsync in practice,
> >
> > It would be interesting to know how you measure performance as one could
> > think of many metrics:
> >
> > - speed on different data
> > - speed on similar data
> > - reliability in face of simultaneous synchronizations
> > - reliability in case of bad network
> > - usage of resources
> > - confidentiality
> > - ...?
> >
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa.inria.fr/sympa/arc/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> >
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 5303 bytes --]