Can the internal `FFIConverter*` types be hidden? about uniffi-rs

[mhammond]

We recently saw mls because it aligns with work we are planning to do and was quite excited to see uniffi used there, then saw your name attached to it and it all made sense :)

In general, this sounds great. Some of these symbols probably do need to be "public" because they are referenced from other modules, but I'm fairly confident our test suite will cover all these cases - but they can probably be "hidden" (whatever that means for the specific binding in question). You mention sub-modules which might work well for some of the bindings - but yeah, we'd almost certainly take PRs for this.

[mgeisler]

We recently saw mls because it aligns with work we are planning to do and was quite excited to see uniffi used there, then saw your name attached to it and it all made sense :)

Nice! 😄 I'm excited too about this effort to bring more MLS to platforms like Android and iOS with the bindings created here!

In general, this sounds great. Some of these symbols probably do need to be "public" because they are referenced from other modules,

Yeah, I don't think we can avoid exposing some parent classes here and there. In Android, we will eventually make the library available via Android Jetpack, and I understand that we have certain API guidelines for this. I'm not sure exactly what this means and if it restricts us in what we can leave public in the generated API.

We have played with the idea of writing a shim API on top of the auto-generated API coming out of UniFFI — but it would of course be ideal to avoid this as much as possible to make maintenance reasonable.

You mention sub-modules which might work well for some of the bindings - but yeah, we'd almost certainly take PRs for this.

Excellent! Then I'll start investigating what is possible and send some PRs to update the output.