Sdl_evolution: SDL 0158 - Revise Cloud App Transport Proposal

[jordynmackool]

Hello SDL community,

The original proposal "SDL 0158 - Cloud App Transport Proposal" was accepted by the Steering Committee on 2018-05-23, alterations to the proposal have been requested through a pull request.

This review will focus on only the changes present in this pull request "SDL 0158 - Revise Cloud App Transport Proposal" begins now and runs through February 5, 2019.

The requested changes for review can be found here:

https://github.com/smartdevicelink/sdl_evolution/pull/663

Note: All comments should be contained in this issue!

The original proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/4a65fd3e69f1a5d8c7dff5286f0df96a79a382c5/proposals/0158-cloud-app-transport-adapter.md

Noted Revisions
Added information related to:

• AppExitReason/Disconnects initiated by HMI
• Specifying auth_token should be included in start service ack payload
• Add GetCloudAppProperties RPC
• Add endpoint param to CloudAppProperties
• Add note about policy security and functional group structure
• Add app_icon url to be used by systemRequest RPCs

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/666

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Jordyn Mackool

[nickschwab]

To avoid unnecessary attribute name prefixing, please change the proposed app_icon_url policy table attribute to icon_url since it is already within an app's contextual struct.

[joeygrover]

Cloud app sends a start service request, and Core responds with a Start Service ACK with the auth_token in the payload.

This is a protocol change so the affecting platforms should be added.

App Icon URL
Can we add language that states Core should cache this image and only request a new image if the url has changed? I believe this will make its way into the core certification guidelines so it would be good to have here.

This might be outside the scope of these changes, but does an embedded app need to use a secure websocket?

Does cloudAppAuthToken need the cloud modifier? Does appAuthToken work fine? Might be better to keep generic now and use the struct it's in for its context. Expanding on that more, is it possible to scrub cloud off some of the definitions and replace it with a different modifier if required? I'm worried there may be confusion when implementing embedded apps. This is not a huge deal for me though.

[JackLivio]

This is a protocol change so the affecting platforms should be added.

Ok.

Can we add language that states Core should cache this image and only request a new image if the url has changed? I believe this will make its way into the core certification guidelines so it would be good to have here.

Sure we can make a note. If there is an app icon in the storage folder then core will not initiate the app icon system request. If the app icon url changes after a policy table update, then core will perform a system request to obtain the new image.

Does cloudAppAuthToken need the cloud modifier?

No. How about we name it authToken?

[jordynmackool]

The Steering Committee voted to accept this proposal with revisions. The revisions will include changing the app_icon_url policy table attribute to icon_url as mentioned in this comment, include the affecting platforms based on the protocol changes mentioned in this comment, and rename cloudAppAuthToken to authToken noted in this comment.
Additionally, the author stated that OEMs have the ability to specify secure websockets or unsecured websockets whether you have WS or WSS specified in cloud_transport_type in the policy table.