[Unison-hackers] Interface for an external GUI

[Tõivo Leedjärv]

On Mon, 6 Feb 2023 at 18:49, Michael von Glasow <michael at vonglasow.com> wrote:
>
> Option 1: recompile the Unison binary (with only the text UI) for
> Android and call that from the GUI.

I know this or something similar has been done
(https://urldefense.com/v3/__https://github.com/bcpierce00/unison/wiki/Software-for-use-with-Unison__;!!IBzWLUs!RLHa3A2snTpIeRCQOWDMiu0DNPhEWg-3ZTB2XetsviJmlWbRwyWXiM3q1DrmXcm6ICeg-k2sgkiTn07YNd5e84Q_7oQ$ 
) but I can't see this being a long-term stable and flexible solution.

> Option 2: run the code through ocamlcc (converting it into C code),
> rework it into a library that exports the necessary functions for the
> GUI, and call that from the GUI via JNI or JNA.

You don't need ocamlcc to achieve the same result (see below).

> As for option 1, can I run the binary in a sort of backend mode that
> supports interactive operation – scan for differences, display
> differences, let user choose how to resolve differences and start
> synchronization, then synchronize – while keeping track of files and
> skipping those which get modified during synchronization? This would
> probably entail multiple calls to the binary – once to collect the
> differences, then to sync them according to the user’s choice – any way
> to do this?

Not really. Yet. I'm positive to making this happen one way or another.

I'm mainly thinking of two possible options.

Option A: linking everything into the same binary and using whatever
FFI is required to call into the OCaml code. This is basically your
option 2 but it can be done without ocamlcc. The current Mac native
GUI uses this approach.

Option B: some kind of IPC with some kind of serialization format to
expose an interface. Yout option 1 is one variant of this (but limited
and brittle without an interface designed specifically for this
purpose).

As you can see, option A is already being used and seemingly working
well (I have never seen the native Mac GUI myself, though). However, I
do not suggest taking this approach right now. At least not the way
the Mac GUI does it. That's because the current implementation is
basically a bunch of duplicated code and lacks a well-defined API.
Assuming a clean universal API is defined and implemented without
(major) code duplication, I see no reason why this approach wouldn't
work in the long term.

Option B offers much more flexibility and less coupling, so without
having thought about the details at all, that's what I would go for.