rinf contains copied flutter_rust_bridge source code?

[fzyzcjy]

Hi, today I found this repository, happy to see the ecosystem of flutter+rust is growing, and curiously looked at the source code (since it does something similar to flutter_rust_bridge). It seems that the engine https://github.com/cunarist/rinf/tree/52fd1f2b06ffd84c528c487aa3a68d53387b40e1/rust_crate/src/engine looks familiar to me - indeed the code in https://github.com/fzyzcjy/flutter_rust_bridge/tree/master/frb_rust/src.

I am (almost) sure you are not deliberately stealing code - since rinf is open source, and you have contributed to FRB :) Therefore, I am quite curious why the code is copy-pasted, instead of using the dependency system? I am afraid copy-pasting will let rinf lose future bugfixs, feature updates, etc, from flutter_rust_bridge.

[temeddix]

Hi @fzyzcjy , thank you for leaving your opinion :)

Indeed, Rinf has some code and ideas brought from other projects, as written here:

• Pioneers who paved the road #104

What Rinf is trying to do is to provide new values(such as easier integration, faster setup, reliable workflows) to the ecosystem around Flutter and Rust. That's why we are using the MIT license to contribute to this open-source system.

I've tried to make Rinf depend on flutter_rust_bridge before, but unfortunately the exact behavior of flutter_rust_bridge didn't really meet our demands. Let me list some of the few core issues that we've faced:

• [Bug] FlutterRustBridgeBase should be singletons fzyzcjy/flutter_rust_bridge#1373
• On the web, with flutter_rust_bridge, the new tasks are always spawned in a new web worker(and SyncReturn doesn't work). We're using the async system over threads, and therefore had to implement a single-threaded web executor in the engine.
• We want Rust code to run on the main thread on native platforms, but inside a web worker on the web.

So if you look deeper, you will notice quite a lot of modifications, especially inside parts that are related to the web.

Also, the communication system between Dart and Rust here is quite simple - we just need to pass a few integers and binary messages between Dart and Rust(Without datetimes, etc). Threrefore, one of the goals here is to slim the engine code.:

• https://github.com/orgs/cunarist/projects/9

In short, Rinf couldn't make flutter_rust_bridge change its behavior to match ours. It was a whole new topic, and we had different approaches. flutter_rust_bridge outperforms in terms of creating custom FFIs. In contrast, we are taking the minimal approach, believing that keeping the connection logic as simple as possible can be less error-prone and provide decent app development experience(rather than library development experience).

[fzyzcjy]

Hi, thank you for the reply.

Things like further simplifying the dependency chain, documentation, etc in flutter_rust_bridge has been a part of the plan since the early days. I felt happy to saw Rinf being a high level wrapper of flutter_rust_bridge.

By the way, some thoughts about Rinf's approach - passing around messages via Protobuf serialization: Indeed, when I created flutter_rust_bridge, that approach was one of the options I considered, and even implemented and used in production.

Quoting my own StackOverflow Q&A-style post in How to call Rust functions in Flutter (Dart) via FFI, but with convenience and safety? - Stack Overflow:

The first way that I have used in the production environment for a year is that, you can use JSON or Protobuf to pass all the data between Rust and Dart/Flutter.

With drawbacks - in addition to abstract reasoning like "FFI-codegen-based is the widely-used approach" - I considered at that time as follows:

Despite its convenience (only a bit of unsafe boilerplate), the drawback is also evident. The serialization and deserialization does not come for free. You will have to pay the CPU time and memory for it, which can be quite large sometimes. Moreover, you cannot easily pass around big objects. For example, if you have an image (you know, at least megabytes of size), serializing it to Protobuf, then deserialize it from Protobuf can be quite a waste of both CPU and memory - useless copies! Even worse, since Flutter/Dart FFI does not support a convenient way of async FFI, you have to make it running in a separate worker isolate - one more memory copy. You can see more here: dart-lang/language#1862 (this is an issue that I opened).

Anyway, wish you success!