Work on a joint statement about the importance of native messaging

[frivoal]

@mikepie1 @frivoal and @dprophet to work on a joint statement about the importance of native messaging, to be used to inform the TAG and other relevant W3C groups about the importance of the topic, and potentially trigger work on it.

[frivoal]

Meeting minutes: http://browserext.github.io/minutes/2016-09-22.html

[frivoal]

First draft / stub written here: https://github.com/browserext/native-messaging/wiki/Explainer:-the-need-for-native-messaging

[frivoal]

As per the last meeting, I need to try and organize a meeting with web payment people to discuss this.

[guest271314]

If still a viable concern, am willing to help in this effort, by contributing as an independent individual, with all contributions being PUBLIC DOMAIN. Do not have any interest in joining any formal group.

An updated version of Native Messaging could include use of SharedArrayBuffer, WebAssembly, WASI, TransformStream and Transferable Streams https://bugs.chromium.org/p/chromium/issues/detail?id=910471#c18

Native Messaging with MessagePort not necessarily as extension code

This is something that interests me. I've found the extension native messaging API hard to use, and it's not useful for the drive-by web. One problem I can see is that there is necessarily an OS-specific aspect in how it interfaces with a native app, and that's unusual and difficult to handle from an open web standard perspective.

instead of limiting messages to 1024*1024, see WebAssembly/WASI#297.

Here use the host more to execute shell scripts than for the actual messaging, which can now be done by writing STDOUT to files and reading the files using Native File System; while WICG/file-system-access#97 was closed at WontFix, achieved the requirement using inotify-tools, as explained at https://github.com/guest271314/requestNativeScripts.

The permissions model could also be updated to be similar to Native File System API at Chromium, where the user can grant read/write permission to one or more directories, which would eliminate the need to hardcode externally_connectable

"permissions": [
    "nativeMessaging"
  ],
  "externally_connectable": {
    "matches": ["https://example.com/*"],
    "ids": ["pcabbmdaomgegmnmljpebgecllcgbfch"]
  }

or dynamically overwrite the property value.

Native Messaging has certainly been helpful here achieve results not possible by implementations or strictly defined by specifications.

• https://github.com/guest271314/native-messaging-espeak-ng
• https://github.com/guest271314/native-messaging-mkvmerge
• https://github.com/guest271314/captureSystemAudio/tree/master/native_messaging/launch_pavucontrol

Yes, concur, Native Messaging is important.

Is the goal to preserve the original specification, or update the specification given the updates to technologies shipped as of date and the varierty of use cases possible, provided updates to the specified mechanisms of communicating with a native host?