On 01/05/15 00:42, Jet Villegas wrote:
I wonder why we'd allow *any* parsing differences here?
If we're also signing up to increase spec compliance as part of the rewrite, that should be called out as an explicit goal
rust-url (https://github.com/servo/rust-url/) was originally written per the URL standard (https://url.spec.whatwg.org/) for Servo and the rest of the Rust ecosystem (replacing a something that was at the time part of the Rust standard library). The idea to use it in Gecko only came up recently.
Where rust-url diverges from Gecko’s currently behavior, I’d rather consider case by case which should be changed (including possibly changing the spec) rather than systematically align with what Gecko happens to be doing.
On 01/05/15 19:58, Gregory Szorc wrote:
Shipping *any* Rust component as part of Gecko is already going to be a long and arduous task. I think it makes sense for the first Rust component in Gecko to be a drop-in, behavior identical replacement. i.e. don't bloat scope to include behavior changes that could jeopardize the deliverable.
All true.
It would be really unfortunate if we did all this Rust preparation work only to have the feature utilizing it backed out because of behavior differences.
I expect Rust support in the build system to land separately from any code that uses it: https://bugzilla.mozilla.org/show_bug.cgi?id=oxidation
But this is a very high-level observation. I know others spent a lot of time figuring out what to Rust-ify first and URL parsing was eventually chosen. If you say it is the least risky part of Gecko to swap out, I trust that assessment.
URL parsing will not necessarily be the first Rust component to land. There is also work going on on MP4 parsing (https://bugzilla.mozilla.org/show_bug.cgi?id=1161350), and we’ve discussed BMP decoding as a low-risk component.
On 05/05/15 21:55, Jonas Sicking wrote:
Will this affect our ability to make nsStandardURL thread-safe?
I don’t know of any thread safety issue in rust-url. It’s only doing string manipulation.
On 06/05/15 04:07, Boris Zbarsky wrote:
Note that performance has been a recurring problem in our current URI code. It's a bit (10%) slower than Chrome's, but about 2x slower than Safari's, and shows up a good bit in profiles.
I haven’t looked into rust-url’s performance at all. This means two things: it’s probably not great right now, but it can probably be improved.
For example, the Url struct currently contains a vector of strings for the path and a some more strings for other URL components. Each (non-empty) string is a memory allocation. It would probably be more efficient to have a single string with some indices delimiting the components.
Some of this may be due to XPCOM strings, of course, and the fact that there's a lot of back-and-forth between UTF-16 and UTF-8 involved, but some is just the way the URI parsers work.
rust-url uses the String type from the Rust standard library, which is based on UTF-8.
If conversions to/from UTF-16 turn out to take significant time I could imagine making the parsing code generic over the string representation.
-- Simon Sapin _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
