In yrs, the lifetime of a transaction is determined automatically. This can
lead to an interesting situation in Ruby, where we attach a listener to receive
changes, never commit a transaction explicitly and where the transaction gets
dropped automatically. I believe we still maintain a pointer to the transaction
that no longer exists, and therefore we receive a segfault.
It is not clear if this ends up being the final API to receive changes, but
it is the one that is supported in one or the other way across all yrs
implementations. It might be beneficial to add a synchronous API in the future,
but this isn't supported right away. All common styles of closure like behavior
are supported: Proc, Lambda and Block.
In a meeting with the wider y-crdt group on May 6th, 2022, it became clear
that the cost of creating a new instance of a data type is common operation in
many languages (Python, Ruby, …), but it is not something we should to support.
This pattern leads to all sort of problems, mostly because it contradicts the
common usage pattern of replicating changes between two or more clients.
Instead, the API should be explicit about this fact and should not make it too easy to do that.
The developer should not be exposed to transactions until they need to change the default logic in any way. If someone creates a structure and inserts, removes, this should be part of the same transaction until stated otherwise.
It might be interesting to sync at a more granular level, but for the sake of simplicity, the first iteration of this library will only support synchronization of the complete document.
The internal API (y-crdt) is subject to constant changes and does not
necessarily offer an idiomatic Ruby interface. Therefore, the public API of
y-rb does not follow the y-crdt API, but prefers familiar Ruby idioms when
possible and might even require libraries where it makes sense (e.g. nokogiri for XML).
The Ruby<->Rust binding feels immature. But it is not the goal of this project to fix this immediately. The long-term vision is to replace this part by something more lightweight and opinionated that could be part of the Rust codebase of this project.