[Unison-hackers] Interface for an external GUI

[Greg Troxel]

Michael von Glasow <michael at vonglasow.com> writes:

> After a decade of using Unison, it might be time for me to start
> tinkering, as I realize that Unison is missing an Android port. (I did
> find one, but it seems to be proprietary and, judging by the
> screenshots, has lots of room for improvement.)

Interesting - I had no idea one existed.  The main codebase is GPL3, so
a non-GPL3 port (vs a reimplementation of the protocol) seems
surprising.

> Since I have little knowledge of OCaml, much less of OCaml on Android,
> my approach to an Android port would be to build a pure Android GUI
> that calls the native Unison binary for all the backend work. I see
> two possible options to accomplish this:

Perhaps, but with NDK and having unison code in the apk, it might be
ok.  That more or less implies the ocamlcc method.

> Option 1: recompile the Unison binary (with only the text UI) for
> Android and call that from the GUI.

Have you tried Termux?  It might have ocaml and it might work.

I think syncthing is using your option 1.

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

There's a concept lurking which is to library-ize parts of unison to
make it callable from CLI, GUI and external RPC.  That might be
partially ok, and it might be useful.

> Has anyone ever tried one of these two and can share their experience?
> What did you get to work, what did not work?

You are going to need to think about storage management rules.  Android
has gotten difficult about this.  The app (apk) that has unison is going
to need storage manager permission.  Which means termux is not going to
really work, but it's an interesting POC.

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

I think this is the library-ization I refer to.


Some links that might or might not be helpful:

  https://urldefense.com/v3/__https://jaredforsyth.com/posts/making-a-cross-platform-mobile-game-in-reason-ocaml/__;!!IBzWLUs!XoyhOAnx7cc1FhYryelGKgTsVN25DONk9l1NQK3zQUCSm9ruNTZiCStEMfz0OZEjTYsQHiIcz6GZdpvkjEtCSF2q$ 

  https://urldefense.com/v3/__https://github.com/ocaml-cross/opam-cross-android__;!!IBzWLUs!XoyhOAnx7cc1FhYryelGKgTsVN25DONk9l1NQK3zQUCSm9ruNTZiCStEMfz0OZEjTYsQHiIcz6GZdpvkjB68Vw18$