[Unison-hackers] Interface for an external GUI

[Michael von Glasow]

On Tue, 7 Feb 2023 15:26:35 +0100, Tõivo Leedjärv 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.
Indeed, even the author says: “*Caution:* Although I use Gunison daily, 
it is less reliable than Unison itself (and will always be, if only 
because it parses Unison’s human-readable output).” That is an issue 
with any CLI, unless it explicitly distinguishes between what git calls 
plumbing and porcelain – plumbing is intended to be called by other 
programs, therefore console output is in a format that is sufficiently 
well-defined and stable to be parsed by a program. Then again, parsing 
CLI output might not be the most elegant way to begin with.
> 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.
That is quite close to what I am attempting to do.
> 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).

Actually I was thinking of something far less complex:

unison -just-report-diffs-without-touching-anything <profile>

unison {-left-to-right|-right-to-left} -lefthash <hash> -righthash 
<hash><path> <profile> # once for each file that is not skipped

– basically, a plumbing-style CLI, but that isn’t exactly elegant. It 
would have been a quick win, had Unison already provided the necessary 
functionality – but if I need to modify Unison anyway, it’s not worth 
the effort. Better turn it into a library with a somewhat well-defined 
API that a frontend can call.

> 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.

I haven’t dug deeply yet into the Objective-C to OCaml bindings, but I 
see the Mac GUI does a few things involving thread creation and the 
like, which I interpret to mean that it’s not as simple as a few 
function/method calls. But with the assumption of the clean universal 
API, this would be my preferred architecture.

So challenges for me would be:

* compiling Unison for Android in the first place (through one of Greg’s 
links I discovered https://urldefense.com/v3/__https://github.com/vouillon/opam-android-repository__;!!IBzWLUs!XRYhymUdJQzornokn_snO3BE4GBc1BNVFDOcLc6QSiwC2mBN4pgM4wOAEUhRAbtZAHdniwJz7-lQCGy0_CmWOC64ysEnA0af$  
and just saw that Jerôme, the author, is also a Unison contributor and 
even mentions Unison in one of the examples)

* figuring out how the Mac GUI interfaces with the rest of the Unison code

* figuring out if I can just call OCaml code directly from Java via JNI, 
or if I need to first create a C wrapper around it

* if necessary, write the C wrapper

* get the toolchain to build a library of the OCaml code – and the C 
wrapper, if necessary

After that, I would build the Android UI around the library – after 
mastering the previous challenges, that part would just be routine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20230207/06c5aee7/attachment.htm>