Mapping icu4c APIs?

[eerhardt]

I work on the .NET runtime team. We are looking into the feasibility of using icu4x in .NET when publishing a .NET application to a client workload. The first place we'd like to enable this is in a Blazor WebAssembly application.

Today we are using icu4c for both server and client workloads. You can see the list of icu4c APIs we are using.

I was wondering if there is a mapping (either directly, or rough mapping) between the icu4c APIs and the icu4x APIs. So I could see what functionality we'd need to call in icu4x to enable the same scenarios we are doing in icu4c today.

[zbraniecki]

Hi @eerhardt!
Great to hear from the .NET team! Based on your description and my understanding of the .NET platform ICU4X project seems very well aligned.
Saying that, I'd like to manage expectations - we're still in an early stage of development. We released 0.1 in October 2020 and are currently working on the 0.2 release.

In particular, one of our goals is to serve as a write-once-use-everywhere ICU model and for that purpose we are investing in strong FFIs, but it's really early and 0.2 is aiming to introduce a first, if humble, proof of concept of that.

If you're interested in trying ICU4X, the 0.1 and the current main branch are both suitable to explore integration for several of the APIs you listed like locale canonicalization and basic date time formatting.

If you'd be open to collaborate with us, your use case list is strongly aligned with our roadmap, your participation would be well aligned with our 1.0 plans and allow us to achieve the wider API scope earlier.
From a cursory review of the list, only IDNA is out of scope for us, but we do plan to serve as a platform for an independent Rust crate for that purpose (providing underlying Unicode data).

Let us know if you'd like to chat further and we can set up a call to discuss this further!

[eerhardt]

Thanks for the information, @zbraniecki. Sorry it took so long to reply, sometimes my day job gets in the way 😉.

If you're interested in trying ICU4X, the 0.1 and the current main branch are both suitable to explore integration for several of the APIs you listed like locale canonicalization and basic date time formatting.

I've been trying to carve out some time (hopefully in the next few weeks) to put together a proof of concept of .NET using ICU4X for the basic date formatting scenario in a WebAssembly application. I think that will give me the background I need to have a better discussion about our needs.

From a cursory review of the list, only IDNA is out of scope for us

Yeah, I wouldn't expect client-side apps to need that. So I think that is fine.

Let us know if you'd like to chat further and we can set up a call to discuss this further!

Yes! I think that would be great. Thanks for the offer. Give me some time on my end to do some learning and prototyping. I'll ping back here when I am ready to set up a call.

[eerhardt]

@zbraniecki - I've finally gotten time to get back to prototyping using ICU4X in .NET. I was wondering if you (and anyone else who is interested) had some time to set up that call to discuss further. You can find my email address in my GH profile, if you want to send me some contact details.

I was able to get the library loaded, and can call functions from .NET. The first issue I've hit is that the data files we are using are .dat files. We load the .dat file into memory, and call udata_setCommonData in ICU4C to set this as the current data. I don't see a provider that would handle this functionality. We are super size conscience in this area (which is why we are investigating using ICU4X in the first place), so I'm not sure on the best approach forward. Is there a better data format than .dat files to use? If necessary, would we need to write a DataProvider that provided the data from in-memory .dat files?

Looking forward to chatting with you.

[zbraniecki]

Hi @eerhardt - sure! I'll shoot you an email (and get Nebojsa on CC!) and we can plan a chat.

I'll also separately respond a bit here, in case someone else stumbles upon this thread and is curious about where we are on the question - Generally speaking, ICU4X is aiming to provide much better data management capabilities through our DataProvider API. It does mean that we'll work with different (smaller, more modular, and faster to load) resource files than ICU4C.

We are about to release 0.2 and start testing it's integration into a product (for the test production env. we will be using Firefox and SpiderMonkey), so within several months we should have that path validated and some initial documentation on how to hook that into your project.

[sffc]

In-memory .dat-like files for ICU4X are in scope for ICU4X 0.3. Here's the tracking issue: #78

In the mean time, you can load data from the filesystem. Instructions: https://crates.io/crates/icu_provider_fs

I also filed #664 to follow up on documenting this better.

[nciric]

Hi @eerhardt,
great to hear .NET team is interested in ICU4X project! Btw. I agree with @zbraniecki assessment of the state of the project and would like to invite you to contribute and help us speed up the development.

I would like to learn more about your exact needs:

1. Would you use Rust interface or do you need C API
2. How important is to exactly match your list of C API, i.e. if we provide C API, does it have to be 1:1 with your list?

[eerhardt]

Hi @nciric, nice to meet you.

would like to invite you to contribute and help us speed up the development.

Thanks! I'm not sure I can commit to anything major, especially in the near term. But maybe if there is a small fix we need to unblock our scenarios, I may take you up on that.

Would you use Rust interface or do you need C API

.NET has the ability to P/Invoke (platform invoke) into a stable "C" API. I was chatting with @CoffeeFlux (on my team) about how we could do this, and I think either approach would work for us. Today we have our own "thin C wrapper" code around ICU4C that we make the jump from .NET to C. And in our thin wrapper, we handle calling into ICU4C APIs. Using this same approach to call into ICU4X should work. We can make the jump from our C code to Rust ourselves. Or if ICU4X exposes C APIs, we could call into those from our C code.

Either way, I guess we would like to invoke ICU4X from C code.

How important is to exactly match your list of C API, i.e. if we provide C API, does it have to be 1:1 with your list?

Having the identical API isn't important. But what is important is the high-level scenario. For example, being able to get the currency symbol for a locale, or the name of a calendar, or a string collation, etc. If there is a different way to accomplish the same thing, I am completely fine with calling different APIs between ICU4X and ICU4C.

[nciric]

Hi @eerhardt
we have a contributor landing PRs for .net FFI bindings for ICU4X that may be of use to you.

As we are not .net developers it would be great if somebody from your team could look at them for correctness.

rust-diplomat/diplomat#124 (landed, but are there any issues?)
rust-diplomat/diplomat#126 (landed)