[SDL 0240] WebEngine support for SDL JavaScript

[theresalech]

Proposal: WebEngine support for SDL JavaScript

This proposal is adding a new transport to the SDL JavaScript library to support (progressive) web apps to run on a WebEngine or a browser.

Review: smartdevicelink/sdl_evolution#767

Steering Committee Decision:

The Steering Committee voted to accept this proposal with the following revisions:

• When formatting locales in the manifest.json file, use standard (RFC 5646), and convert locale strings when necessary.
• Do not specify the location of the manifest's <script> tag placement within the proposal.
• All revisions included in this PR: https://github.com/smartdevicelink/sdl_evolution/pull/888/files

The proposal .md file was updated to reflect these revisions on 12/19/19.

[vladmu]

@theresalech @crokita @nickschwab after some review of the SDL-0240 proposal and the current state of develop, we see that the new WebSocket Client Transport and SDL.js package are already in place.

According to this, we would like to ask, what additionally expected as the solution to the current issue?

Also, at first glance, it seems this js example could be adjusted to be used as an example for this proposal. All that is needed is just replace the hardcoded host, port, and protocol (ws/wss) of WebSocket initialization to use corresponding values from the URL's GET parameters.

The second question is: could this adjustment be the solution of the current issue, would it be a good idea to put this WebEngine example into this repository, e.g., in sdl_javascript_suite/examples/WebEngine/hello-sdl?

[crokita]

@vladmu Yeah, that example JS app uses a websocket client connection, which connects to the java proxy program in the same directory that routes the packets via TCP so that we could test functionality.

That idea sounds correct, in that the JS app could pull in those parameters from the URL and override the defaults. Both options sound feasible, whether it's making the JS app compatible with WebEngine as well, or just putting the WebEngine JS app in its own folder. I'm tempted to say the latter option is better, and to make the directory /examples/webengine/hello-sdl when we're ready to include it.

[theresalech]

@vladmu while you're working on this implementation, as the manager layers are not yet complete, we were hoping to confirm that this feature will be implemented in the LifecycleManager in a way which provides flexibility to easily relocate to the manager layers once they're ready. Can you please let us know? Thank you!

[vladmu]

@vladmu while you're working on this implementation, as the manager layers are not yet complete, we were hoping to confirm that this feature will be implemented in the LifecycleManager in a way which provides flexibility to easily relocate to the manager layers once they're ready. Can you please let us know? Thank you!

@theresalech I'm not sure what changes in the LifecycleManager do you mean, because as I said before, I see all required things for WebEngine are already in the library? I've prepared the PR with working example for WebEngine. What additionally expected here except this example, and WebSocket Client and sdl.js package existing in library?

[nickschwab]

@vladmu According to the proposal (0240):

The SDL JavaScript library should use the manifest file by reading the exported const to automatically send RegisterAppInterface and ChangeRegistration instead of using a configuration or builder pattern. The SDL library may need a new method to attempt to import and utilize the manifest.js contents. This need should be an implementation detail as it would only affect library internals.

My interpretation of this is that a new public method would need to be offered in the JavaScript API to attempt to register the application using the contents of the manifest file, rather than requiring a developer to manually parse out pieces of the manifest to send in an RAI request within their app logic.

For example, in a completely finished state being integrated into SdlManager, a developer might do something like this:

<script src='manifest.js'></script>
...
await SdlLibrary.manager.SdlManager.loadManifest(sdl_manifest);

[vladmu]

@nickschwab Thank you for the detailed explanation. Currently, the library doesn't have SDL.manager.SdlManager class, therefore, I put loadManifest method into AppConfig class, which is the most suitable place at the moment, in my opinion.

[theresalech]

Proposal markdown file has been updated per the revisions included in accepted Evolution Proposal SDL 0240 Revisions - WebEngine support for SDL JavaScript. These revisions change the appID parameter within GetAppProperties to policyAppID and add a minlength of 1 to the param. Please see the proposal markdown file for more details.