Lines Matching +full:- +full:- +full:all +full:- +full:features

3 In the years since the Chromium browser was first open-sourced, the `//net`
6 both in the Chromium browser and in other Google and third-party products
14 To make it easier to contribute new features or to change existing
26 constraints, see [Supported Projects](supported-projects.md). When
30   * Does this feature apply to all supported projects, or is this something
31     like a Browser-only feature?
32   * Does this feature apply to all supported platforms, or is this something
38   * Does it depend on Google services or Google-specific behaviors or
39     features?
56 In general, `//net` features try to support all platforms with a common
57 interface, and generally eschew OS-specific interfaces from being exposed as
60 Cross-platform code is generally done via declaring an interface named
61 `foo.h`, which is common for all platforms, and then using the build-system to
62 do compile-time switching between implementations in `foo_win.cc`, `foo_mac.cc`,
66 OS-specific considerations, and can instead code to the interface.
102 around as a naked/raw pointer, this is generally seen as an anti-pattern
103 and not to be mirrored for new features.
139 that the `//net` team strongly encourages all new code pass explicit
150 of these patterns, see [Code Patterns](code-patterns.md).
162 done lazily, referred to as "late-binding".
164 With late-bound sockets, a given `URLRequest` will not be assigned an actual
167 get preferential treatment, but it also means that features or data associated
171 For example, a feature that wants to associate the low-level network socket
183 involved fetching a `/.well-known/` URI or reporting errors to a particular URL.
185 This is particularly challenging, because often, these features are implemented
188 on. Because `//net/url_request` depends on these low-level directories, it would
193 patterns. The lower-level directory will define some interface that represents the
201 challenges to contributing and maintaining `//net`. As a consequence, features
205 The `//net` stack is designed heavily around a sync-or-async pattern, as
206 documented in [Code Patterns](code-patterns.md), while also having a strong
208 consequence, features should have precise, well-defined lifetime semantics
210 have web-observable side-effects, it is often required for tasks to have
212 are met, features should attempt to model object lifetimes as a hierarchical
214 weak pointers as part of any of the exposed API contracts (even for features
215 only consumed in `//net`). Features that pay close attention to the lifetime
221 features in `//net` also expect that if a `base::{Once, Repeating}Callback` is
224 object. As further expanded upon in [Code Patterns](code-patterns.md), features
232 of the design philosophy to ensure behaviors are well-specified, and that the
239 …n of [incubation first](https://groups.google.com/a/chromium.org/d/msg/blink-dev/PJ_E04kcFb8/baiLN…
241 With an incubation first approach, before introducing any new features that
247 direct path to an appropriate standards track. Features which don't adhere to
249 require high-level approvals, to ensure that the Platform doesn't fragment.
258 ideally with cross-vendor interest. Particularly, headers which only apply to
264 any lower-level components that may need to make additional requests, for most
265 features, that's not all that is necessary. Because `//net/url_request` only
269 even basic interactions with optional features like Extensions or SafeBrowsing.
271 To account for all of these things, any resource fetching that is to support
279 tries to define how all resource loads in the Web Platform happen - whether
286 well-documented way, thus minimizing platform fragmentation and security
296 In general, prior to implementing, try to get a review on net-dev@chromium.org
299 In addition to the net-dev@chromium.org early review, `//net` requires that any
300 browser-exposed behavior should also adhere to the
301 [Blink Process](https://www.chromium.org/blink#new-features), which includes an
302 "Intent to Implement" message to blink-dev@chromium.org
304 For features that are unclear about their future, such as experiments or trials,
305 it's also expected that the design planning will also account for how features
306 will be removed cleanly. For features that radically affect the architecture of
313 Plan for obsolence, hope for success. Similar to implementation, features that
315 [Blink Process](https://www.chromium.org/blink#TOC-Web-Platform-Changes:-Process)
316 for removing features.
318 Note that due to the diversity of [Supported Projects](supported-projects.md),
321 safety of removing a feature may not consider all projects, and relying on
323 work on all projects either.
326 adding features, because they may represent multi-year commitments to support,