Giter Club home page Giter Club logo

Comments (10)

tarikeshaq avatar tarikeshaq commented on August 18, 2024 1

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.

jhugman avatar jhugman commented on August 18, 2024 1

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.

badboy avatar badboy commented on August 18, 2024 1

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:

  1. There's the Rust code (both the implementation and the FFI parts)
  • Some initial scaffolding for this would be great.
  1. 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)
  1. 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
  1. ... 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.

tarikeshaq avatar tarikeshaq commented on August 18, 2024

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.

rfk avatar rfk commented on August 18, 2024

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.

rfk avatar rfk commented on August 18, 2024

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.

rfk avatar rfk commented on August 18, 2024

@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.

rfk avatar rfk commented on August 18, 2024

transferring this repo as-is to the mozilla org in github

FYI I am going to go ahead and do this ^

from uniffi-rs.

rfk avatar rfk commented on August 18, 2024

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.

rfk avatar rfk commented on August 18, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.