Changes

Jump to: navigation, search

Oxidation

197 bytes removed, 20:13, 6 December 2018
Recommendations
* For components where Servo has demonstrated success.
In terms of where to keep Rust crates, there are three options, from most-coupled to least-coupled.
* Put the crate in mozilla-central or in Servo's repository.
** For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depend depends on the details of the binding code in question.* Put the crate on [https://crates.io crates.io] and use Cargo to access it at build-time.** This is only suitable for highly general-purpose crates, such as <tt>smallvec</tt>.
* Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central.
** This works well if relatively few people are working on the crate, and the API isn't too complex.** Can be useful if useful development can be done using just that crate, without the rest of Gecko or Servo.** This also makes sense for pre-existing third-party crates that we choose to import.** This Otherwise, this option is done by WebRender, for example.* Put the crate somewhere else (e.g. [https://crates.io crates.io])not recommended, and use Cargo to access it at build-time.** This because vendoring is only suitable for highly general-purpose cratessomething of a hassle.
In general, erring on the side of tighter coupling is advisable. For example, the <tt>heapsize</tt> crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called <tt>malloc_size_of</tt> (stored in Servo's repository) because that was easier than modifying <tt>heapsize</tt>.
Confirm
1,345
edits

Navigation menu