Roadmap for 0.2.0

[nugmanoff]

Hey @ObuchiYuki @heckj, here's the draft for roadmap for the 0.2.0 release as I see it. I would love to have your input on this one to decide what we need to prioritize/add/remove.

I will be updating this message as we proceed with the discussion.

Following are improvements that I think should be included in the next release:

• Expose iterator directly from Rust
  • Basically it means wrapping iter() method in Rust directly. Right now iteration is pretty naively implemented – it just collects all values upfront and then iterates over them. Direct iterator wrapping will enable us to have better support for Sequence, Collection types on the Swift side.
• Verify interoperability with other language bindings. Probably start by interacting with simple yjs-based web app.
• Improve usability of Attributes and Embeds to allow more streamlined experience of working with rich text (think – NSAttributedString)
• Implement lib0
  • @ObuchiYuki already ported here most of it. We'd just need to implement it as top-level coder and fully conform to Codable.
• Leverage lib0 encoding/decoding to pass complex types instead of JSON String.
  • We already started discussing it with Joe, I think we can continue it there as well #7
• Nested types
• Implement YProtocol
  • Same as with lib0, we can reuse Yuki's implementation

Below are things that I think can wait:

• Separate TransactionMut & Transaction in Rust wrapper
  • Make Concurrency support more fine-grained
  • Right now all transactions that are created through Rust wrapper are TransactionMut – it is done so for simplicity purposes. But it does come at a cost, because TransactionMut does more job than just Transaction so it makes sense to separate between them for the Rust wrapper/YSwift as well.
• Transaction Events
• Undo/Redo Manager
• Awareness
• Integration with Lexical

[heckj]

Conceptually, sounds great.

While we added basic Embed support in 0.1.0, it was far from obvious for me as to how to use it to represent styled/attributed text strings and reasonably/successfully convert from YSwift to either AttributedString or NSAttributedString for iOS and macOS apps. This may just be me needing to learn more, but I wonder if it's actually usable yet from the Swift side of things.

I think there's a huge case for starting to verify interop with the other Y-CRDT sets of libraries. We should be good based on Yrs underpinning, but I think a small bit of sample interacting with a Web-based app of some form might be extremely worthwhile to showcase what's possible, and worthy of inclusion in 0.2.0

For the lib0 work - I think that's super interesting, and @ObuchiYuki implementation is lovely - but as a very direct port from lib0 itself, I fear it'll be awkward for arbitrary folks using YSwift to adopt. If I'm understanding the lib0 work correctly, anyone wanting to encode their own types using lib0 will need to implement their own conformance to LZCodable - which is set up as entirely separate from Codable, the iOS and macOS serialization standard (roughly equivalent to serde in Rust). I think we may want to make a top-level encoder implementation that's based on https://github.com/ObuchiYuki/lib0-swift, but fully implements the Codable protocol. If the goal is to serialize our own types, then this is extra work that isn't needed, so correct me if I'm off-base on my understanding there.

The benefit I see to enabling lib0 encoded results from a Codable conformance would be two fold - one, more compression than standard JSON encoding (I'm guessing there, but it seems likely), and two - better interoperability with javascript, python, or ruby types that are encoded on other platforms and that we want to seamlessly work with through YSwift.

[nugmanoff]

Agree with everything you mentioned.

Embeds and Attributes definitely need more clarity – that's the thing that wasn't clear to me when I was doing it as well. It is just inherited from yrs. And interop thing is also very important to verify, because that's the whole point of making a language bindings – so that everything works smoothly across different languages and runtimes.

I overlooked the part that Yuki's implementation doesn't conform to Codable but instead introduces its own protocol.
You are more than right with your proposition to implement lib0 as top-level encoder and implement the Codable protocol fully. That's definitely the goal here.

I'll clarify these in the pinned message.