Roadmap about y-crdt HOT 14 CLOSED

@fivestones @heckj We've got the plans to create a Swift language binding for Yrs. This is not something that either me or @dmonad will be directly coding, but rather a position for another independent programmer. We want this to be open sourced as part of organization and this is going to be a paid work.

I wanted to make this public after we release v0.13 (which'll introduce quite a few API changes), but since this topic bubbled up there's no reason to hide it.

from y-crdt.

@fivestones, I think the question goes a bit beyond what would be useful in this roadmap issue, but I'd be happy to at least try and aim you in the right direction. I made an XCFramework by building the Rust/C raw interfaces and then wrapping around that, but it's not a "swift" oriented interface at all - just a raw C one that's exposed to swift. The whole sequence of how and what I did is documented in the repo where I was experimenting: https://github.com/heckj/YrsC

Why don't you open an issue there with any questions (after you have a look at what's there) and I can at least share my knowledge of what's happening with the whole quandry of "using Rust libraries from within an iOS app". For anything Yrs oriented about the API, probably a separate issue here about whatever element of that API you're working with and having trouble would make more sense.

from y-crdt.

👋 I don’t know how far I’ll get, but wanted to let you know i was trying out the FFI interface for use with Swift language bindings. I have the static libraries compiled and available using the raw C api (https://github.com/heckj/YrsC) and am starting to experiment with idiomatic swift around that to make it more usable (https://github.com/heckj/yrs-swift-experiment). Happy to contribute any or all upstream to this project, but also learning the ins and outs of wrapping C apis in swift, so don’t feel terribly comfortable asserting anything about quality ;-)

from y-crdt.

Ah, I see. You are building the Yffi package. That's the right way if you want to bind directly to the C interface.

Btw: Yffi is a shorthand for Y Foreign Function Interface. It generates the C bindings that we support.

I recommend researching a bit more whether there is a better way to bind directly to the Rust interface. The Rust interface is much easier to consume. A solution might be https://mozilla.github.io/uniffi-rs/ or https://github.com/nvzqz/swift-bindgen

We use similar tools in Ypy and Ywasm and it seems much easier to maintain.

from y-crdt.

Hey @Horusiath, thanks for the great news! I am just curious what would be the criterias for the independent programmer to be honored to work on this one on behalf of the Y Organization? The reason I am asking is that I would be quite interested to give it a shot.

from y-crdt.

I've opened a new issue on this #217 - we'll be discussing the details with @dmonad next week. In the meantime if you have any questions, feel free to ask there.

from y-crdt.

I'm closing this one. I'll be creating either a version-scoped or time-constrained (quarterly or annual0 roadmap plans in separate issues.

from y-crdt.

From what I've seen, Observers are usually hard/very unergonomic in Rust due to ownership issues. gtk-rs uses something similar to Observers with callbacks and I'm not sure how that's turned out.
Maybe an event-loop like system instead? Though it might not be a big deal.
(Assuming this is for yrs, sorry if it's not.)

from y-crdt.

@Horusiath @dmonad Hey, do you know if anyone has started looking at JVM bindings? Thanks!

from y-crdt.

@Yam76 I feel observers are not that unergonomic in Rust. Even if they were unergonomic, we need a way to observe document changes. Observers are a required feature for most language bindings.

@ukarlsson Several people have looked into it, but I don't know about anyone seriously working on this. Unfortunately, there doesn't seem to be an easy-to-use Rust binding to the JVM. There are, however, some libraries that allow you to bind C code. This could be used to bind to Yffi (the C bindings to Yrs).

Another alternative might be to run Yjs in Nashorn.

from y-crdt.

Thanks for sharing @heckj! Looking forward to some updates from you :)

FYI: There's already a raw C API for Yrs: Yffy (or is there a difference?)

from y-crdt.

I think that might be what I'm using - the Yrs (https://github.com/y-crdt/y-crdt) generates a C-focused FFI library from the rust implementation, and that's what I used to build the multi-package Framework to import and use from swift with https://github.com/heckj/YrsC (That's a quirk of using the swift language - there's some notable awkwardness in handling the interface of C libraries into swift across the various platforms). That one was labelled "Yffi" - is there another (preferred one) with a slightly different name that I should use? (Yffy? or was that just a typo/autocorrect thing?)

from y-crdt.

@Yam76 I feel observers are not that unergonomic in Rust. Even if they were unergonomic, we need a way to observe document changes. Observers are a required feature for most language bindings.

My bad, I wrote that a while ago. With more experience, I've realized that Serde uses the observer pattern to great effect, so observers can in fact be used ergonomically in Rust. Maybe they can be used here too.

from y-crdt.

@dmonad @heckj I'm trying to figure out how to make use of y-crdt in an iOS swift app. Have either of you been able to successfully do this? I've seen a few tutorials about using rust code in a swift app, but most of them are a few years old and I've run into problems trying to get it to work with the newer current versions of rust, xcode, and swift. Do either of you have any pointers for me or know of a tutorial that explains any of this? Thanks!

from y-crdt.