summaryrefslogtreecommitdiffstats
path: root/mobile/android/android-components/docs/rfcs/0003-concept-base-component.md
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-05-15 03:35:49 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-05-15 03:35:49 +0000
commitd8bbc7858622b6d9c278469aab701ca0b609cddf (patch)
treeeff41dc61d9f714852212739e6b3738b82a2af87 /mobile/android/android-components/docs/rfcs/0003-concept-base-component.md
parentReleasing progress-linux version 125.0.3-1~progress7.99u1. (diff)
downloadfirefox-d8bbc7858622b6d9c278469aab701ca0b609cddf.tar.xz
firefox-d8bbc7858622b6d9c278469aab701ca0b609cddf.zip
Merging upstream version 126.0.
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'mobile/android/android-components/docs/rfcs/0003-concept-base-component.md')
-rw-r--r--mobile/android/android-components/docs/rfcs/0003-concept-base-component.md33
1 files changed, 33 insertions, 0 deletions
diff --git a/mobile/android/android-components/docs/rfcs/0003-concept-base-component.md b/mobile/android/android-components/docs/rfcs/0003-concept-base-component.md
new file mode 100644
index 0000000000..bac4385057
--- /dev/null
+++ b/mobile/android/android-components/docs/rfcs/0003-concept-base-component.md
@@ -0,0 +1,33 @@
+---
+layout: page
+title: Adding a `concept-base` component
+permalink: /rfc/0003-concept-base-component
+---
+
+* Start date: 2020-07-20
+* RFC PR: [#7776](https://github.com/mozilla-mobile/android-components/pull/7776)
+
+## Summary
+
+Adding a `concept-base` component for basic interfaces needed by multiple components.
+
+## Motivation
+
+We already have a `support-base` component that contains basic building blocks, like a logger, that other components may need. Some of those building blocks are interfaces, like `CrashReporting` that are implemented by other components (e.g. `lib-crash`). This works well in most cases, but becomes problematic once a `concept` component requires such an interface. Having a `concept` component depend on actual code with `support-base` is breaking our contract of concepts only depending on other concepts.
+
+* In [#7689](https://github.com/mozilla-mobile/android-components/issues/7689) I want to introduce a `Profiler` interface that allows other components to add profiler markers. The Firefox profiler provides this functionality in our `browser-engine-gecko*` components (exposed by `concept-engine`). If this interface lives in `support-base` then `concept-engine` would need to depend on `support-base`.
+* In [#7775](https://github.com/mozilla-mobile/android-components/issues/7775) I want to introduce an interface that allows components to make leaks detectable.
+
+## Reference-level explanation
+
+We introduce a `concept-base` component that contains those "basic" interfaces. Other components and concepts can depend on this component. This component will be the home for the `Profiler` interface ([#7689](https://github.com/mozilla-mobile/android-components/issues/7689)) and leak detection interface ([#7775](https://github.com/mozilla-mobile/android-components/issues/7775)).
+
+In addition to that we can move interface-only pieces from `support-base` to `concept-base`: `CrashReporting`, `MemoryConsumer`.
+
+## Drawbacks
+
+* This introduces another base component that most other components will depend on. Since it only contains interfaces the impact of that will be low though.
+
+## Rationale and alternatives
+
+* Alternatively we could create distinct `concept` components for every interface theme. This would end up with a very fine-grained list of components that mostly may contain only a single interface. This would also break with the idea that a concept describes a component that will have an actual implementation component (e.g. `concept-toolbar` -> `browser-toolbar`). Interfaces like `MemoryConsumer` are not describing a full component, but instead just one unified aspect of it.