Potential collaboration with ICU4X

[Manishearth]

Hi!

I'm posting this in a slightly different capacity: with my hat as an ICU4X member.

We've been working on Rust internationalization stuff in https://github.com/unicode-org/icu4x, and folks are starting to look into bidi. There's a general reluctance to duplicate code that exists in the Rust ecosystem, especially a widely-used crate like unicode-bidi, so in general the team would prefer to share code with unicode-bidi if possible.

I explained to the ICU4X team that since unicode-bidi is at the bottom of so many deptrees (in particular, it gets pulled into basically any http stack via url/idna code), it would be quite unlikely for unicode-bidi to take a dependency on any ICU4X component, even if ICU4X is trying to be super modular. However, ICU4X could take a dependency on unicode-bidi (and would be happy to help maintain it).

For ICU4X to be able to use unicode-bidi, a couple changes would need to happen:

• it should be possible to opt out of unicode-bidi's precompiled data and supply your own (ideally via a trait). I'm working on a draft PR to prototype this.
• a couple bits of functionality would need to be exposed (@younies is investigating what exactly needs to be done; but the basic idea is "the things Skia needs", which might involve exposing some things based on currently-private internal state)

What do folks think? Does this, in general, sound like a good idea? With my Servo hat on it would definitely be nice to have more folks maintaining this repo, and overall both types of changes don't seem like a major deal here.

cc @jdm @mbrubeck @behnam

[mbrubeck]

This sounds good to me.

[clarfonthey]

Might also be worth talking to the folks over at open-i18n/rust-unic as they are also the second biggest authority on Rust unicode libraries.

[Manishearth]

(yeah behnam is UNIC)

[Manishearth]

Closing since we've been operating with that collaboration for most of this year, and it's been going well.