-
Notifications
You must be signed in to change notification settings - Fork 8
/
use-cases.html
277 lines (276 loc) · 13.6 KB
/
use-cases.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
<!DOCTYPE html>
<html>
<head>
<title>
Use cases for the navigator.connect() API
</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove'>
</script>
<script class="remove">
// (this is to make tidy happy)
// See http://www.w3.org/respec/ for ReSpec documentation.
var respecConfig = {
specStatus: "unofficial",
shortName: "navigator-connect-api",
editors: [
{
name: "Marijn Kruisselbrink",
company: "Google",
companyURL: "https://www.google.com/"
},
],
edDraftURI: "https://mkruisselbrink.github.io/navigator-connect/use-cases.html",
noLegacyStyle: true,
otherLinks: [{
key: "Participate",
data: [
{ value: "File bugs and feature requests",
href: "https://github.com/mkruisselbrink/navigator-connect/issues",
},
{ value: "Fix the text through GitHub",
href: "https://github.com/mkruisselbrink/navigator-connect",
},
],
}],
};
</script>
</head>
<body>
<section id='abstract'>
<p>
This document provides a collection of use cases for cross origin communication between
<a>Service Worker</a>s and webpages.
</p>
</section>
<section id='sotd'></section>
<section>
<h2>
Introduction
</h2>
<p>
This document will use the term <code><dfn>navigator.connect</dfn>()</code> to refer to the
notional API that allows cross-origin communication between <a>Service Worker</a>s and web
pages. This isn't intended to presuppose the final shape of the API, although we don't know
of any alternate proposals.
</p>
<p>
Cross-origin communication between two web pages or between a web page and a <a>Service
Worker</a> is currently possible, using an iframe and channel messaging, for example.
However, no such direct communication is possible between two <a>Service Worker</a>s. The
use cases in this document are intended to illustrate how communication between two
<a>Service Worker</a>s, which is enabled by <code><a>navigator.connect</a></code>, creates
opportunities for more intelligent, efficient, and elegant web apps and services.
</p>
</section>
<section id="usecases">
<h2>
Use-Cases
</h2>
<section id='analytics'>
<h2>
Offline Analytics
</h2>
<p>
Third party analytics platforms expose their services via REST interfaces. Thus, these
platforms are unable to provide insights about offline behavior. As <a>Service
Worker</a>s and offline web apps become more prevalent, the need for analytics platforms
that function offline will continue to grow.
</p>
<p>
<code><a>navigator.connect</a></code> enables third party analytics platforms to register
<a>Service Worker</a>s that expose APIs to track metrics both online and offline. These
<a>Service Worker</a>s are then able to report these metrics when connectivity is
reestablished so that they can be consumed by the developer. Furthermore, this reporting
can be implemented with background sync to take advantage of times when the user’s
experience will not be impacted—for example, avoiding saturating the network with
non-essential requests when the user is struggling with poor connectivity or on a heavily
metered/throttled mobile plan. Thus, exposing analytics APIs via <a>Service Worker</a>s
allows third party analytics platforms to reduce their performance costs even when
online.
</p>
<p>
Note that without <code><a>navigator.connect</a></code>, a web app frontend could report
metrics to an analytics platform <a>Service Worker</a> via communication through an
iframe. However, a web app’s <a>Service Worker</a> would not be able to communicate with
the analytics platform in this way. Web app <a>Service Worker</a>s perform crucial
tasks—both online and offline—that are valuable for developers to track.
<code><a>navigator.connect</a></code> enables the <a>Service Worker</a> to <a>Service
Worker</a> communication that is necessary for this robust web app analytics model.
</p>
</section>
<section id='storage'>
<h2>
Cloud Storage Platforms
</h2>
<p>
Suppose Google Drive offers a <a>Service Worker</a> that provides access to the user’s
files in the cloud, as well as a caching mechanism that keeps high priority files
available for offline access. We want to implement a web app for offline document reading
on both mobile and desktop called Readle.
</p>
<p>
When the user saves an online document to Readle, Readle’s <a>Service Worker</a> loads
the document into temporary storage and uses the Drive API—exposed by the Drive
<a>Service Worker</a> via <code><a>navigator.connect</a></code>—to save the document to
the cloud. Without <code><a>navigator.connect</a></code>, Readle’s frontend would have to
take care of this work, and the saving of a large document could be interrupted if the
frontend were closed prematurely.
</p>
<p>
Once a document is saved to Drive, it is added to a queue of documents to read with
Readle. On desktop, hard drive space can be plentiful, so Readle keeps many documents in
the Drive <a>Service Worker</a>’s cache. On mobile, storage is a scarcer resource, so
Readle selectively tells the Drive <a>Service Worker</a> to cache only the next few
documents in the queue.
</p>
<p>
Suppose the user reads a few documents from the top of Readle’s queue on her desktop. In
a world without <code><a>navigator.connect</a></code>, Readle on the user’s mobile device
can’t start syncing the new top of the queue until the frontend is loaded. With
<code><a>navigator.connect</a></code>, Readle can use push messaging to send the new top
of the queue to its mobile <a>Service Worker</a>, which can then notify the Drive
<a>Service Worker</a> which new documents to cache. With sufficient notice, Drive's
<a>Service Worker</a> can intelligently pull down these files in the background such that
they are available quickly and offline the next time the user opens Readle on the mobile
web.
</p>
</section>
<section id='fonts'>
<h2>
Shared Fonts
</h2>
<p>
Fonts are a shared resource where latency is critical. People expect the text on a web
page to be readable while the images and/or videos load. Latin fonts are 50-200 KB and
download in 0.5 to 1.0 seconds, which is sluggish but acceptable. Chinese/Japanese/Korean
(CJK) fonts are 4-20 MB and download in 10 to 30+ seconds, which is unacceptably slow.
</p>
<p>
Having a way to preload and persist fonts locally can provide a much better user
experience for CJK (and also Latin) users. The browser cache provides a rudimentary
persistence mechanism, allowing a font drawn from a given URL to be retrieved from the
server once and served locally many times. However, the browser cache falls short of the
ideal implementation. For example, when a font is changed, the browser cache does not
realize it is stale until a web page next requests the font. The
<code><a>stale-while-revalidate</a></code> Cache-Control extension can allow the
requesting web page to use the stale font without delay, but the request will cause the
new font to be downloaded while the user is actively using the network for other
purposes. In an ideal world, the download would be performed intelligently via background
sync at a time when bandwidth is abundant and cheap. Additionally, a smarter persistance
method would efficiently download the font deltas, which are undoubtedly far smaller than
the entire font.
</p>
<p>
Alternatively to the browser cache, local persistence mechanisms such as IndexedDB can be
used to reduce redundant font requests over the network. However, such local persistence
mechanisms are domain specific: if the same font is used in multiple domains, it must be
persisted separately for each domain.
</p>
<p>
In contrast, a cross domain service can reduce unnecessary latency and storage costs for
fonts (and other such shared resources) with greater customized intelligence than the
browser cache. Such a cross domain service can be implemented in the form of a fonts
<a>Service Worker</a> and <code><a>navigator.connect</a></code> protocols. This
implementation opens up additional opportunities as well. For instance, the fonts
<a>Service Worker</a> can use the background sync API to schedule rationalization and
optimization work when the network and CPU are idle, including:
</p>
<ul>
<li>Optimizing the cache for efficiency by removing rarely used fonts
</li>
<li>Fetching complete fonts to replace previously downloaded subsets
</li>
<li>Updating fonts to their newest versions
</li>
<li>Automatically fetching the most popular fonts for a given user
</li>
</ul>
<p>
Note that a shared fonts service could be implemented without
<code><a>navigator.connect</a></code>, although it would be quite awkward. With
<code><a>navigator.connect</a></code>, the optimization can happen in the background,
with a web app’s <a>Service Worker</a> handling the front end’s font request and
communicating with the shared fonts <a>Service Worker</a> as necessary. In this way,
<code><a>navigator.connect</a></code> enables a transparent and elegant solution that
avoids the need to alter CSS loading.
</p>
<p class='issue'>
TODO(slightlyoff): add more details on the difference between the with- and
without-<code><a>navigator.connect</a></code> implementations.
</p>
</section>
</section>
<section id="nongoals">
<h2>
Non-Goals
</h2>
<section id='extension'>
<h2>
Extending the Platform
</h2>
<p>
Browsers have a number of ways to expose functionality to web developers. Most commonly,
browsers expose standardized Javascript APIs to web pages and Service Workers. However,
browsers can expose arbitrary, unstandardized functionality with Javascript APIs as well,
although this is uncommon due to the danger of this game. Similarly, browsers can expose
platform features via URL endpoints. With current technologies, such exposed APIs could
be invoked by web pages through <code><iframe
src="<var>implementation://defined.uri/</var>"></code> combined with
<code>postMessage</code>. <code><a>navigator.connect</a></code> could similarly allow
such a URL endpoints to be accessed by Service Workers.
</p>
<p>
However, this use case is a non-goal. It is unlikely to drive aspects of the proposed
API. Should exposing platform features to Service Workers via URL endpoints prove
valuable in the future, it will require a detailed analysis of how to make it safe for
the web before recommending or supporting it.
</p>
</section>
</section>
<section id="security+privacy">
<h2>
Security and Privacy Considerations
</h2>
<p>
User agents should not leak any information on sites a user has visited etc to other
webpages, unless the visited site opts in. In particular this means that a service
rejecting a connection attempt should be indistinguishable from no service being installed
to service a particular URL.
</p>
<p class="issue">
If attempting to connect to a service can trigger installation of a service worker, we need
to fill in the security and privacy concerns around doing that.
</p>
</section>
<section id='glossary' class='appendix'>
<h2>
Glossary
</h2>
<dl>
<dt>
<dfn>Background Sync API</dfn>
</dt>
<dd>
See <a href=
"https://github.com/slightlyoff/BackgroundSync/">https://github.com/slightlyoff/BackgroundSync/</a>.
</dd>
<dt>
<dfn>Service Worker</dfn>
</dt>
<dd>
See <a href=
"https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html">https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html</a>.
</dd>
<dt>
<code><dfn>stale-while-revalidate</dfn></code>
</dt>
<dd>
See <a href=
"http://tools.ietf.org/html/rfc5861#section-3">http://tools.ietf.org/html/rfc5861#section-3</a>.
</dd>
</dl>
</section>
</body>
</html>