[Unison-hackers] Interface for an external GUI
Tõivo Leedjärv
toivol at gmail.com
Tue Feb 7 09:26:35 EST 2023
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.
More information about the Unison-hackers
mailing list