Comments (10)
For more context, we wanted the library to be pulled into glean and compile with it into one package that A-C can use. So this included having my own uniffi
generated library and having that become a part of the glean binary so A-C can consume it directly. uniffi
generates a separate binary and it seemed more painful to figure out how glean and my library can be packaged together (for a quick prototype at least) than it was to just go the old-school route and have glean pull in my code. I also wanna bring up that we are still keeping the uniffi
option open for the actual thing, but all this is just about the prototype.
Although I admit, my limited experience with packaging in android might have guided me towards "Doing the thing that is done everywhere" faster than it would have if I knew more about Gradle 😅.
I'm trying to think abstractly about "What could have uniffi
done for me, that would have made it work". And the most ambitious answer to that lies in megazording, maybe if there was a way for me to just modify the .build-config.yaml
file in glean and automagically my library is now a part it, then that would've probably made things easier. This obviously ignores the actual complexity there since the library would need not to assume which binary the bindings are in until it's built, but I'm just brain dumping here in hopes that something I say brings perspective 😅.
Now, this was a very specific use case and the "package with glean" experiment does seem a little out ambitious, but maybe it draws some similarities to a use case in a new A-S component that wants to merge into the megazord 😄
from uniffi-rs.
I'm leaning towards 3) promote this to a mozilla project or 4) keep working on this until it's more ready to promote to a mozilla project.
Whichever, writing FFI bindings by hand is not an option (1), and to make generating those bindings a more complete and tractable project it can't be limited to just app-services (2).
from uniffi-rs.
Chiming in as one of the Glean devs here.
You have my support for 3) or 4). I'd like to see this expanding into something we can all benefit from (that includes the a-s, Glean and potentially nimbus project)
Some more thoughts on why Glean would profit from it.
Note: I havent' yet looked much closer at the state of this project, so some things might already be there.
Having some sort of code gen tool/ffi-bindgen/glean-bindgen is on my long "i want that"-list, I just didn't have the holiday rfk used to get it started ;)
Glean is rapidly expanding the number of metric types exposed to users. Each metric comes with a lot of boilerplate to support the different bindings we have (which is now 4 languages: Kotlin, Swift, Python and C#, and will soon expand to 2 more: C++ and JavaScript).
Bindings usually don't need to hold on to much state, so it's more or less a copy'n'paste from other parts. That still leads to some inconsistencies, and at worst bugs because of mismatches across the bindings and the FFI.
For us there's multiple layers I can see being generated:
- There's the Rust code (both the implementation and the FFI parts)
- Some initial scaffolding for this would be great.
- There's the FFI declarations (mostly for Kotlin and C#, the others can use C headers)
- This could even be a translation of the generated C header to Kotlin/C# and I have a script that sorta does it (very hacky)
- Then there's the wrapper (in half a dozen languages)
- They are not fully stateless yet, so a mix of full and scaffold generation would be what we want
- ... and then there's some utility code around that
- This is mostly translations between internal data structs/enums/..., they could be fully auto-generated (the C header is already used in Swift and Python)
(Just summarized that yesterday here: https://bugzilla.mozilla.org/show_bug.cgi?id=1654565)
I think my team would agree and we could offer some dev help in the future.
Nonetheless of what the final decision here will be I plan to take a closer look, possible after next week (after I talk about doing Rust cross-platform and calling for a *-bindgen solution ;))
from uniffi-rs.
I experimented a bit with using uniffi
for component work, The biggest issue I faced is the "Integration with appservices megzording logic".
But I think if we can figure that out - I guess if we push into A-S then that is a motivator to figure it out - then (from my very limited experience) I think there is merit to giving it a shot.
We spoke briefly about uniffi
for Nimbus, and the Glean team seemed as excited as we are in exploring it. Since if it works out, there is a potential of it saving the Glean team time as well in the long run! So I don't think it lies in the "Failed experiment" bucket just yet.
Just adding a quick context on my 'prototype' I ended up going the 'classic' FFI route because my prototype ended up compiling with Glean and uniffi
doesn't (YET!) have a way to integrate with other libraries.
Also, a bit of personal opinion that I think this is worth it because I remember when starting off my internship I looked at the FFI code as something that I definitely don't wanna touch without being SUPER careful, and I still do look at it that way 😅.
Anyways just my 2 cents as someone new to the team!
from uniffi-rs.
my prototype ended up compiling with Glean and uniffi doesn't (YET!) have a way to integrate with other libraries.
Thanks for the feedback! I'm curious to hear more about the chain of dependencies here and what uniffi did (or lacked) that prevented you from integrating with glean. I don't think I have a complete enough mental model of the moving parts to go "aha yes, this would have failed because of X" just yet.
from uniffi-rs.
From discussion in team meeting today, it sounded like we were leaning towards transferring this repo as-is to the mozilla
org in github. I'll wait a couple of days for any other comments or suggestions, but if we don't pick anything else, I'll go ahead and make that change this Friday 24th July, Australian Eastern Standard Time.
from uniffi-rs.
@tarikeshaq thank you, that's exactly the sort of feedback I was hoping for; I filed https://github.com/rfk/uniffi-rs/issues/27 to follow up on that thread a little bit.
from uniffi-rs.
transferring this repo as-is to the mozilla org in github
FYI I am going to go ahead and do this ^
from uniffi-rs.
Hrm, actually given the caveats around transferring ownership and maintaining admin permission, I'm going to wait until Monday to make the move 😅
from uniffi-rs.
The repo has now been transferred, pending restoration of admin access in Bug 1655623. Thanks for the discussion all, and I look forward to continuing the various threads above.
from uniffi-rs.
Related Issues (20)
- Use C structs/tagged unions for Records/Enums HOT 2
- Store return values in RustCallStatus
- Using proc-macros for constructor requires Arc<Self> HOT 4
- Accessing Vec<u8> in swift HOT 2
- Use a single buffer for all data
- Better Buffer packing
- Use the `FfiValue` type for all arguments HOT 1
- `HandleAlloc::clone_handle` and `consume_handle` should be marked unsafe HOT 3
- Rust pointers can have both even and odd addresses HOT 4
- `RustCallStatus::error_buf` should be `ManuallyDrop`, not `MaybeUninit`?
- Add implemented traits to generated code, or add extension? HOT 2
- [Swift] Would it be possible to use checked exceptions? HOT 6
- Only invoke cargo metadata for desired targets HOT 7
- Add a conversion pass before rendering the bindings templates HOT 3
- How to get Rust panic backtrace?
- Swift classes are not generated properly with their Protocol as Generic Type HOT 2
- Interface/Protocol use in foreign generated code HOT 4
- FR: Optionally disable exception catching in foreign trait code
- Tell the bindings about traits implemented by objects.
- Allow trait interfaces without a Send + Sync bound
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from uniffi-rs.