OLD | NEW |
1 Chrome Platform Services | 1 Chrome Foundation Services |
2 ==== | 2 ==== |
3 | 3 |
4 ### Overview | 4 ### Overview |
5 | 5 |
6 This directory contains Chrome Platform Services. If you think of Chrome as a | 6 This directory contains Chrome Foundation Services. If you think of Chrome as a |
7 "portable OS," Chrome Platform Services can be thought of as that OS' "system | 7 "portable OS," Chrome Foundation Services can be thought of as that OS' |
8 services". | 8 foundational "system services" layer. |
9 | 9 |
10 Roughly each subdirectory here corresponds to a service that: | 10 Roughly each subdirectory here corresponds to a service that: |
11 | 11 |
12 * is a client of `//services/shell` with its own unique Identity. | 12 * is a client of `//services/shell` with its own unique Identity. |
13 * could logically run a standalone process for security/performance isolation | 13 * could logically run a standalone process for security/performance isolation |
14 benefits depending on the constraints of the host OS. | 14 benefits depending on the constraints of the host OS. |
15 | 15 |
16 ### Service Directory Structure | 16 ### Service Directory Structure |
17 | 17 |
18 Individual services are structured like so: | 18 Individual services are structured like so: |
(...skipping 12 matching lines...) Expand all Loading... |
31 libraries from outside of `//services`. Dependencies to large platform | 31 libraries from outside of `//services`. Dependencies to large platform |
32 layers like `//content`, `//chrome` or `//third_party/WebKit` must be avoided. | 32 layers like `//content`, `//chrome` or `//third_party/WebKit` must be avoided. |
33 | 33 |
34 ### Physical Packaging | 34 ### Physical Packaging |
35 | 35 |
36 Note that while it may be possible to build a discrete physical package (DSO) | 36 Note that while it may be possible to build a discrete physical package (DSO) |
37 for each service, products consuming these services may package them | 37 for each service, products consuming these services may package them |
38 differently, e.g. by combining them into a single package. | 38 differently, e.g. by combining them into a single package. |
39 | 39 |
40 ### High-level Design Doc | 40 ### High-level Design Doc |
41 https://docs.google.com/document/d/15I7sQyQo6zsqXVNAlVd520tdGaS8FCicZHrN0yRu-oU/
edit#heading=h.p37l9e7o0io5 | 41 https://docs.google.com/document/d/15I7sQyQo6zsqXVNAlVd520tdGaS8FCicZHrN0yRu-oU/
edit#heading=h.p37l9e7o0io5 |
| 42 |
| 43 ### Relationship to other top-level directories in // |
| 44 |
| 45 Services can be thought of as integrators of library code from across the |
| 46 Chromium repository, most commonly //base and //mojo (obviously) but for each |
| 47 service also //components, //ui, etc in accordance with the functionality they |
| 48 provide. |
| 49 |
| 50 Not everything in //components is automatically a service in its own right. |
| 51 Think of //components as sort of like a //lib. Individual //components can |
| 52 define, implement and use mojom interfaces, but only //services have unique |
| 53 identities with the Mojo Shell. |
OLD | NEW |