diff options
| author | Paul Frazee <pfrazee@gmail.com> | 2018-05-30 15:01:33 -0500 |
|---|---|---|
| committer | Paul Frazee <pfrazee@gmail.com> | 2018-05-30 15:01:33 -0500 |
| commit | e339c9b7369477ea38c1aef6d7d8d27429d029d0 (patch) | |
| tree | 82810df4e4b09cf5b33106f80eadfe2e58bfd8f3 /proposals | |
| parent | 833f0b8bbc96e379ba2ad48c30a964ec7d2eddd7 (diff) | |
| download | dat-deps-e339c9b7369477ea38c1aef6d7d8d27429d029d0.tar.gz dat-deps-e339c9b7369477ea38c1aef6d7d8d27429d029d0.zip | |
Expand on rationale in proposals/0000-session-data-extension.md
Diffstat (limited to 'proposals')
| -rw-r--r-- | proposals/0000-session-data-extension.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/proposals/0000-session-data-extension.md b/proposals/0000-session-data-extension.md index 659e70d..56e39e4 100644 --- a/proposals/0000-session-data-extension.md +++ b/proposals/0000-session-data-extension.md @@ -51,9 +51,9 @@ After publishing this DEP, the "Beaker Browser" will implement a Web API for exp # Rationale and alternatives [alternatives]: #alternatives -Some applications have used the `peer id` and/or `userData` fields of the replication handshake message in order to broadcast this information. Those mechanisms are unsuitable for Web applications (as in the "Beaker browser") because the sites' applications are not executed reliably prior to the replication handshake. +Some applications have used the `peerId` and/or `userData` fields of the replication handshake message in order to broadcast this information. Those mechanisms are unsuitable for Web applications (as in the "Beaker browser") because the sites' applications are not executed reliably prior to the replication handshake. By using an extension message, we provide the same presence & discovery without relying on the timing of the application-code execution. -By using an extension message, we provide the same presence & discovery without relying on the timing of the application-code execution. +An alternative approach would be to establish an ephemeral messaging channel, perhaps using a different extension message. This ephemeral channel would broadcast the payload to the client's application code as an event when it is received, but would not retain the most recent payload as session-data. This ephemeral channel would be less effective in Web applications (as in the "Beaker Browser") because it would rely on the application-code being active (loaded in a tab) at time of receipt, whereas the builtin session-data semantic makes it possible for the browser to retain the last payload on the applications' behalf. # Changelog |