I created C bindings for Yrs so I could test it out in Swift. This could be useful for others looking to bridge with Yrs.
Custom provider was left out intentionally. I think it could be better implemented in the host language. Please let me know your thoughts.
This is great, thanks for sharing! I want to make Yrs very portable. So your experience in creating a c-binding is very valuable.
Does this mean we don’t need a dedicated Swift binding? Does a c-binding suffice for Swift?
There’s still a lot work on the Swift side for a smoother dev experience. The provider pattern, for instance, could be implemented in native Swift using Combine framework (Rx). It would help make the API more idiomatically Swift.
This is where I want to get your thoughts on. Would it make sense to limit Yrs to just the core CRDT functions: get_type, encode_update, apply_update, get_array, get_map, etc. Leave concerns such as provider, undo/redo in the host language.
It will absolutely be possible to write providers in the host language as well (this is a requirement anyway). Although I see some advantages in porting providers as well (reduced maintenance overhead, protocol-compatibility across language-ports). This really depends on the use-case. Both will be possible.
If there there are language features, or if there is a de-facto standard framework that usually handles communication in the host language, we can hook into it as well.