[Unison-hackers] Interface for an external GUI

[Tõivo Leedjärv]

On Tue, 7 Feb 2023 at 20:28, Michael von Glasow <michael at vonglasow.com> wrote:
>
> Then again, parsing CLI output might not be the most elegant way to begin with.

It could be. If the output (and, accordingly, input) is designed
specifically for this purpose then it can be a perfectly valid way.

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

Right, this is not worth the effort. The problem with this approach is
not the interface. This approach requires runtime state to be always
persisted, and that's a big change. Plus, I'd imagine this would
became rather inefficient with larger roots/number of updates.

> Better turn it into a library with a somewhat well-defined API that a frontend can call.
> 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.

There is some non-trivial amount of housekeeping and boilerplate to be
done, for sure.

I personally would advise not to go this object-linkable library
route. Not because it wouldn't work, but because it is a more
inflexible and tightly coupled way with no immediately obvious
benefits. Does it make the backend or the UI implementation simpler?
No. Does it offer better performance or resource usage? Maybe a
little. Does Android make it hard/impossible to have multiple
processes or a meaningful IPC? In that case, yes, this option is
better.

I would prefer the IPC option because it's just more flexible in every
way. It can be used by not only UIs but also other "clients" and
frontends. You could use the same UI with different versions of Unison
(and even upgrade them separately, if needed) and even with multiple
Unisons at the same time. Depending on the design, it could be
possible to connect/disconnect to a running process as needed. The
language of UI/"client"/frontend would be completely independent of
the backend's. No worrying about FFI, bindings and C wrappers and so
on. And finally, if really desired, the linkable library interface can
be built on top of this solution afterwards.

Just to be clear, I don't mean that you would have to do any of this.
I am myself interested in this concept as a universal solution and am
willing to implement the backend bits if/when there is a design
created and agreed upon (which I'm also willing to help with).

If think this would make your life much easier too. Let's say we
decide to pick some easily used and widely available mechanism for
IPC: (local/network) sockets; and some easily used and widely
available serialization format: JSON (or BSON or similar). Then all
you have to do from Java code is to establish the connection and parse
JSON, completely ignoring all linking issues, language bindings, C
wrappers and JNI. You'd still have to get Unison proper to compile and
work on Android but that's about it.

A would really like to hear others' opinions for a universal solution
like this (not limited to Android GUI).