Is your feature request related to a problem? Please describe.
Diffing multiple times with the same primary from a disassembler is inefficient, as the export process needs to repeated each time
The IDA Pro plugin has a lot of functionality that has to be rewritten for each disassembler with few opportunities to share code (also C++ vs. Java in Ghidra)
The standalone UI also reimplements a lot of functionality of the IDA plugin, leading to subtle differences.
Describe the solution you'd like
Implement a local BinDiff RPC server using gRPC that get started on demand (similar to how Gradle/Bazel start build processes). The UI and other plugins can then start diffs (and the .BinExport will stay loaded in memory) and request flow graphs for view. This would help with implementing #16 as well. It would also enable BinDiff-as-a-service style deployments.
The plugins would become simpler and could be implemented in the repective disassembler's favoured scripting language (Python and PyQt for IDA Pro and Binary Ninja, Java Swing for Ghidra).
Describe alternatives you've considered
N/A
Additional context
It should be possible to implement this and adopt it gradually.
Is your feature request related to a problem? Please describe.
Describe the solution you'd like Implement a local BinDiff RPC server using gRPC that get started on demand (similar to how Gradle/Bazel start build processes). The UI and other plugins can then start diffs (and the .BinExport will stay loaded in memory) and request flow graphs for view. This would help with implementing #16 as well. It would also enable BinDiff-as-a-service style deployments.
The plugins would become simpler and could be implemented in the repective disassembler's favoured scripting language (Python and PyQt for IDA Pro and Binary Ninja, Java Swing for Ghidra).
Describe alternatives you've considered N/A
Additional context It should be possible to implement this and adopt it gradually.