experiments in a post-browser web
more notes
+30
-15
+3
-9
TODO.md
+3
-9
TODO.md
···
22
22
## v? - Extensibility
23
23
24
24
Peek extensions
25
-
- [ ] better name that "extension"
26
-
- [ ] figure out background app vs other
27
-
- [ ] maybe cmd stays in core?
28
-
- [ ] is background runtime aware? eg mobile/extension/desktop
29
-
- [ ] background app separation from "feature" apps, is runtime aware
30
-
- [ ] annotate all data with source creator/editor (sys vs extension)
31
-
- [ ] figure out in-extension settings vs jamming in global settings
32
-
- [ ] syncable settings (extension decides)
33
-
- [ ] App cmds (eg Editor -> cmd to edit note X)
25
+
- [ ] see notes/extensibility.md
34
26
35
27
Web extensions
36
28
- [ ] WebExtension integration for priority only, on some platforms
37
29
38
30
## v? Portability
31
+
32
+
does this need to be done before extensions?
39
33
40
34
- [ ] Common background runtime
41
35
- [ ] Datastore -> background
+27
-6
notes/extensibility.md
+27
-6
notes/extensibility.md
···
2
2
3
3
Balance minimal install/development/distribution barriers with web-level safety at runtime.
4
4
5
+
Key bits:
6
+
5
7
- Extensions are a folder with a PWA manifest and web content files
6
8
- They're opened under the peek:// protocol, each in a web content process
7
9
- Their main window is hidden, like the Peek background content process
8
10
- Extensions are run directly from their local folder (wherever the user selected)
9
-
- Hot reloading, Peek watches folder for changes, and reloads
10
-
- Extensions are managed in the settings app, eg add/remove, enable/disable
11
-
- User can open/close devtools for a given extension
11
+
- Extensions are managed in the main settings app, eg add/remove, enable/disable
12
+
13
+
Implementation
14
+
15
+
- New table in datastore for extensions
16
+
- New section in settings app, where users can:
17
+
- Add/remove
18
+
- Enable/disable
19
+
- Activate/suspend/reload
20
+
- Click to access settings
21
+
22
+
Note: The implementation will also instigate another shift, moving as much logic into the background web app as possible, vs in node.js space, so we can eventually move to other back-ends than Electron.
12
23
13
-
Capabilities:
24
+
Capabilities via injected API:
14
25
15
26
- Window management
16
27
- Datastore access
···
18
29
- Hotkey registration
19
30
- Pubsub messaging
20
31
21
-
Open questions for later:
32
+
Dev workflow:
33
+
34
+
- User can open/close devtools for a given extension (via a cmd)
35
+
- User can reload a given extension (via a cmd)
36
+
- Hot reloading using node fs watcher to watch folder for changes, and reload
37
+
38
+
Open questions, for later:
22
39
23
40
- Dirty writes - add ext or sys as source. also ensure no direct writes, only api adds
24
41
- Sharded space, in/outbox style too maybe
···
28
45
- How to do extension-specific settings? Manifest link to bundled settings UI? Or a api for placement into Settings app?
29
46
- How to allow for maximal unloading vs always persistent
30
47
- How to do remixes, eg take verified extension X, copy and hack
48
+
- figure out in-extension settings vs jamming in global settings
49
+
- syncable settings (extension decides)
31
50
32
-
Mobile:
51
+
Mobile, for later:
33
52
- open web pages
34
53
- if calls a registration api, user can choose to add
35
54
- permissions
36
55
- expose peek api upon approval
37
56
- also, preverification via sync
57
+
58
+