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?

[frivoal]

Hi @guest271314.

Unfortunately, even though browser extensions remain a relevant topic, this group has been dormant due to insufficient active participation to sustain it.

Hopefully, it will one day be restarted, and at that point, I hope your comment helps inform the discussions, and that you will still be interested in participating.

However, for the moment, I need to warn you that you are unlikely to receive an answer (other than this kind of status update).

[guest271314]

"Hopefully" is not a concept that embrace. Facts are measurable.

Am currently concluding testing a Native Messaging application.

What is you measure for active participation?

Why is more than one dedicated individual necessary to maintain this specification and repository?

Chrome evidently announced plans to deprecate Chrome Apps, which Native Messaging currently falls under.

https://developer.chrome.com/apps/nativeMessaging

Important: Chrome will be removing support for Chrome Apps on all platforms. Chrome browser and the Chrome Web Store will continue to support extensions. Read the announcement and learn more about migrating your app.

Native Messaging is not mentioned at the migration page. That indicates Native Messaging will be deprecated.

If that is the case, why not just close the repository ahead of being deprecated by degrees from an implementer action flowing up river?

This is a very useful concept. Again, am willing to help maintain this repository, at bare minimum, the concept.

[frivoal]

"Hopefully" is not a concept that embrace. Facts are measurable.

Ok, let me restate, without subjective opinion.

You (or anyone) may respond to existing issues or open new ones, and others are free to respond. Note however that this group is inactive, meetings are no longer being held, decisions are no longer being made, specifications are no longer been maintained, and comments are few and far between. This situation is not necessarily permanent, but it is the present situation.

See also the warning on the group's home page https://browserext.github.io/

---

Personally, I do not consider it worth my time to engage in technical discussions while implementors are not participating. I regret that they are not, but they are not. As a courtesy to people who take the time to comment, I do take the time to warn them that this group is not currently functional, and that constructive discussions are unlikely. Feel free to ignore me if you don't like it. I have delivered my heads-up, and do not plan to comment on this any further.

[guest271314]

People interested in this work being resumed are encouraged to drum up support among the various implementors.

Issue 1214621: Fugu Request: Native Transferable Streams https://bugs.chromium.org/p/chromium/issues/detail?id=1214621