Diary - EPA-WG updates, thoughts & discoveries
Opened this issue · 7 comments
Embeddable applications got traction on native level:
<script type="shell"> proposes to run native device code from HTML page. It is closed as not relevant but obviously there is a demand for treating HTML as application with native app capabilities.
While the <embed-page /> is addressing the inline content embedding the PWA conventions are covering the implementation of embedding into desktop apps from the text+icon of various sizes, notification preview, up to full vs windowed presentation.
The list of PWA in comparison with Portlet (and other CMS) features TBD.
The integration of EPA requires the messaging between container and embedded app. Current options are:
- postMessage for frame communication
- Web Storage events
<embed-page /> is using the LocalStrage and SessionStorage via prefixing the keys with EPA signatire and domain name. Event notification could be used for communication between client and container.
Could <embed-page />s' approach be used as a candidate for standard?
App data sharing scope
Browsers have given storage API for data key/value preservation. Which also could be used for cross-application communication as during applying the data in start time as in run time via 'storage' event notification.
Secure communication assumes the data and events will be available only between approved by host page applications. I assume the data format compatibility would be guaranteed only between same application (meaning same location.host and location.pathname of <embed-page src=url> ), then probability of data use consistency degrades to host( i.e. api.sample.com ), and domain (sample.com). Which is reflected by scope values page, host, and domain.
Between domains the data in general are not meant to be shared. Meaning better to be insulated in own jailed environment as for data corruption protection as for security reasons. Unless the host page decides to permit the data sharing. In <embed-page name=XXX scope=name src=anyurl> the name=XXX and scope=name attribute define common data space for apps from any url.
Thinking how to fit window.open and window.postMessage API into microapplication concept. Perhaps Clippy is a good sample of such use. But definitely is not that typical. In Windows each app could have commands with parameters. Like "open $file", "print", etc.
And the communication API comprise the app(window) and command for it.
But here is a trouble. postMessage API assumes communication only between child-parent windows.
The window.opener / window.parent given reference to parent( which of course need to be secured by wrapper ) and only(?) way to get reference to sibling window is via window.parent.frames['name'].
Since the random access to microapplications on page is a security issue, only permitted by host app .
Interesting option of prompting for access. Which actually environment does for app say on location or images access. Same is applicable for cross-app communication.
The Chrome team has released an intent to implement on a form of HTML modules: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ewfRSdqcOd8/w_Fr6rJ3DQAJ
It is not a microaplication capable thought. But a good step in right direction.
Check this out:
In light of Google partnering with StackBlitz https://blog.stackblitz.com/posts/introducing-webcontainers/
Introducing WebContainers: Run Node.js natively in your browser
Today we're excited to announce a new technology we've been working on in concert with the teams at Next.js and Google.
A few years ago we realized that the web was heading towards a key inflection point. The advent of WebAssembly and new capabilities APIs made it seem possible to write a WebAssembly-based operating system powerful enough to run Node.js, entirely inside your browser.