(In reply to Petru-Mugurel Lingurar [:petru] from comment #6) > - As Jonathan mentioned, we might need the URI parsing functionality before loading Gecko which [based on this recent investigation](https://bugzilla.mozilla.org/show_bug.cgi?id=1880491#c7) might take ~200ms on a cold start so it would be best to extract this functionality into a new, separate library. I'm not sure I understand why do we need a separate URI parsing functionality, when [said functionality](https://searchfox.org/mozilla-central/rev/5efa5bfe9c217f6ab3529880b25a52ac6405dda8/netwerk/base/nsNetUtil.cpp#1806) is already part of Gecko and is used on Android (as you yourself said above). Can you explain a bit what you mean? > - the `nsIURI` code is tied to other functionalities and extracting it to a separate library is not straightforward, needs additional work Do you mean the C++ code and the XPCOM interfaces? It is not clear to me why would it need to be extracted to a separate library? > - would be better for Android to use this instead. Same would apply to iOS. This will ensure consistency on all platforms. There currently is no way to use rust libraries in a direct way in GeckoView. This is not a trivial problem to solve. Besides, Gecko is not there yet, and it is unclear how long it would take to get there. Our current URI parsing solutions are not ideal from the security stand point. > Implicitly, I think Agi and I had assumed that we would clone nsIUri into it's own library without any other Gecko parts depending on the library. I am not sure what Jonathan assumed, but methods in XPCOM interfaces are essentially C functions, so we can bind to them via JNI. So, what needs to be done here is to write the JNI bindings for the XPCOM interfaces (at a minimum, we would need the `nsIURI` and the `nsISupports`, IIUC, because that is the base interface). The bindings would have to written by hand, as there is no generating code. We can write the generating code, but it's not trivial and would constitute quite a piece of yak shaving, so unless we would have to write a lot of bindings for this project (there are quite a few IDLs around the URI functionality, but it's not clear if we would need them all). Bindings written by hand would have to be kept in sync with the IDLs somehow (not sure how often they change). Whether the resulting Java interfaces would need to be their own library, I don't know. [This comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1685152#c1) seems to be suggesting a use case for a separate java library.
Bug 1685152 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Petru-Mugurel Lingurar [:petru] from comment #6) > - As Jonathan mentioned, we might need the URI parsing functionality before loading Gecko which [based on this recent investigation](https://bugzilla.mozilla.org/show_bug.cgi?id=1880491#c7) might take ~200ms on a cold start so it would be best to extract this functionality into a new, separate library. I'm not sure I understand why do we need a separate URI parsing functionality, when [said functionality](https://searchfox.org/mozilla-central/rev/5efa5bfe9c217f6ab3529880b25a52ac6405dda8/netwerk/base/nsNetUtil.cpp#1806) is already part of Gecko and is used on Android (as you yourself said above). Can you explain a bit what you mean? > - the `nsIURI` code is tied to other functionalities and extracting it to a separate library is not straightforward, needs additional work Do you mean the C++ code and the XPCOM interfaces? It is not clear to me why would it need to be extracted to a separate library? > - would be better for Android to use this instead. Same would apply to iOS. This will ensure consistency on all platforms. There currently is no way to use rust libraries in a direct way in GeckoView (as in: sharing rust libraries with Gecko). This is not a trivial problem to solve. Besides, Gecko is not there yet, and it is unclear how long it would take to get there. Our current URI parsing solutions are not ideal from the security stand point. > Implicitly, I think Agi and I had assumed that we would clone nsIUri into it's own library without any other Gecko parts depending on the library. I am not sure what Jonathan assumed, but methods in XPCOM interfaces are essentially C functions, so we can bind to them via JNI. So, what needs to be done here is to write the JNI bindings for the XPCOM interfaces (at a minimum, we would need the `nsIURI` and the `nsISupports`, IIUC, because that is the base interface). The bindings would have to written by hand, as there is no generating code. We can write the generating code, but it's not trivial and would constitute quite a piece of yak shaving, so unless we would have to write a lot of bindings for this project (there are quite a few IDLs around the URI functionality, but it's not clear if we would need them all). Bindings written by hand would have to be kept in sync with the IDLs somehow (not sure how often they change). Whether the resulting Java interfaces would need to be their own library, I don't know. [This comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1685152#c1) seems to be suggesting a use case for a separate java library.
(In reply to Petru-Mugurel Lingurar [:petru] from comment #6) > - As Jonathan mentioned, we might need the URI parsing functionality before loading Gecko which [based on this recent investigation](https://bugzilla.mozilla.org/show_bug.cgi?id=1880491#c7) might take ~200ms on a cold start so it would be best to extract this functionality into a new, separate library. I'm not sure I understand why do we need a separate URI parsing functionality, when [said functionality](https://searchfox.org/mozilla-central/rev/5efa5bfe9c217f6ab3529880b25a52ac6405dda8/netwerk/base/nsNetUtil.cpp#1806) is already part of Gecko and is used on Android (as you yourself said above). Can you explain a bit what you mean? > - the `nsIURI` code is tied to other functionalities and extracting it to a separate library is not straightforward, needs additional work Do you mean the C++ code and the XPCOM interfaces? It is not clear to me why would it need to be extracted to a separate library? > - would be better for Android to use this instead. Same would apply to iOS. This will ensure consistency on all platforms. There currently is no way to use rust libraries in a direct way in GeckoView (as in: sharing rust libraries with Gecko). This is not a trivial problem to solve. Besides, Gecko is not there yet, and it is unclear how long it would take to get there. Our current URI parsing solutions are not ideal from the security stand point. We can solve these problems by exposing nsIURI, and then we definitely need to start thinking about how to share rust libraries with Gecko. > Implicitly, I think Agi and I had assumed that we would clone nsIUri into it's own library without any other Gecko parts depending on the library. I am not sure what Jonathan assumed, but methods in XPCOM interfaces are essentially C functions, so we can bind to them via JNI. So, what needs to be done here is to write the JNI bindings for the XPCOM interfaces (at a minimum, we would need the `nsIURI` and the `nsISupports`, IIUC, because that is the base interface). The bindings would have to written by hand, as there is no generating code. We can write the generating code, but it's not trivial and would constitute quite a piece of yak shaving, so unless we would have to write a lot of bindings for this project (there are quite a few IDLs around the URI functionality, but it's not clear if we would need them all). Bindings written by hand would have to be kept in sync with the IDLs somehow (not sure how often they change). Whether the resulting Java interfaces would need to be their own library, I don't know. [This comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1685152#c1) seems to be suggesting a use case for a separate java library.
(In reply to Petru-Mugurel Lingurar [:petru] from comment #6) > - As Jonathan mentioned, we might need the URI parsing functionality before loading Gecko which [based on this recent investigation](https://bugzilla.mozilla.org/show_bug.cgi?id=1880491#c7) might take ~200ms on a cold start so it would be best to extract this functionality into a new, separate library. I'm not sure I understand why do we need a separate URI parsing functionality, when [said functionality](https://searchfox.org/mozilla-central/rev/5efa5bfe9c217f6ab3529880b25a52ac6405dda8/netwerk/base/nsNetUtil.cpp#1806) is already part of Gecko and is used on Android (as you yourself said above). Can you explain a bit what you mean? > - the `nsIURI` code is tied to other functionalities and extracting it to a separate library is not straightforward, needs additional work Do you mean the C++ code and the XPCOM interfaces? It is not clear to me why would it need to be extracted to a separate library? > - would be better for Android to use this instead. Same would apply to iOS. This will ensure consistency on all platforms. There currently is no way to use rust libraries in a direct way in GeckoView (as in: sharing rust libraries with Gecko). This is not a trivial problem to solve. Besides, Gecko is not there yet, and it is unclear how long it would take to get there. Our current URI parsing solutions are not ideal from the security stand point. We can solve these problems by exposing nsIURI, and then we definitely need to start thinking about how to share rust libraries with Gecko. > Implicitly, I think Agi and I had assumed that we would clone nsIUri into it's own library without any other Gecko parts depending on the library. I am not sure what Jonathan assumed, but methods in XPCOM interfaces are essentially C functions, so we can bind to them via JNI. So, what needs to be done here is to write the JNI bindings for the XPCOM interfaces (at a minimum, we would need the `nsIURI` and the `nsISupports`, IIUC, because that is the base interface). The bindings would have to written by hand, as there is no generating code. We can write the generating code, but it's not trivial and would constitute quite a piece of yak shaving, so unless we would have to write a lot of bindings for this project (there are quite a few IDLs around the URI functionality, but it's not clear if we would need them all). Bindings written by hand would have to be kept in sync with the IDLs somehow (not sure how often they change). Also, the lifetime of the objects would have to be in sync and probably tied to the lifetime of the Java counterparts, so we will have to make sure we manage the refcounts. Whether the resulting Java interfaces would need to be their own library, I don't know. [This comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1685152#c1) seems to be suggesting a use case for a separate java library.
(In reply to Petru-Mugurel Lingurar [:petru] from comment #6) > - As Jonathan mentioned, we might need the URI parsing functionality before loading Gecko which [based on this recent investigation](https://bugzilla.mozilla.org/show_bug.cgi?id=1880491#c7) might take ~200ms on a cold start so it would be best to extract this functionality into a new, separate library. I'm not sure I understand why do we need a separate URI parsing functionality, when [said functionality](https://searchfox.org/mozilla-central/rev/5efa5bfe9c217f6ab3529880b25a52ac6405dda8/netwerk/base/nsNetUtil.cpp#1806) is already part of Gecko and is used on Android (as you yourself said above). Can you explain a bit what you mean? > - the `nsIURI` code is tied to other functionalities and extracting it to a separate library is not straightforward, needs additional work Do you mean the C++ code and the XPCOM interfaces? It is not clear to me why would it need to be extracted to a separate library? > - would be better for Android to use this instead. Same would apply to iOS. This will ensure consistency on all platforms. There currently is no way to use rust libraries in a direct way in GeckoView (as in: sharing rust libraries with Gecko). This is not a trivial problem to solve. Besides, Gecko is not there yet, and it is unclear how long it would take to get there. Our current URI parsing solutions are not ideal from the security stand point. We can solve these problems by exposing nsIURI, and then we definitely need to start thinking about how to share rust libraries with Gecko. > Implicitly, I think Agi and I had assumed that we would clone nsIUri into it's own library without any other Gecko parts depending on the library. I am not sure what Jonathan assumed, but methods in XPCOM interfaces are essentially C functions, so we can bind to them via JNI. So, what needs to be done here is to write the JNI bindings for the XPCOM interfaces (at a minimum, we would need the `nsIURI` and the `nsISupports`, IIUC, because that is the base interface). The bindings would have to written by hand, as there is no generating code. We can write the generating code, but it's not trivial and would constitute quite a piece of yak shaving, so unless we would have to write a lot of bindings for this project (there are quite a few IDLs around the URI functionality, but it's not clear if we would need them all). Bindings written by hand would have to be kept in sync with the IDLs somehow (not sure how often they change). Also, the lifetime of the objects would have to be in sync and probably tied to the lifetime of the Java counterparts, so we will have to make sure we manage the refcounts correctly. Whether the resulting Java interfaces would need to be their own library, I don't know. [This comment](https://bugzilla.mozilla.org/show_bug.cgi?id=1685152#c1) seems to be suggesting a use case for a separate java library.