[Accepted with Revisions] SDL 0189 - Restructuring OnResetTimeout

[theresalech]

Hello SDL community,

The review of "SDL 0189 - Restructuring OnResetTimeout" begins now and runs through July 24, 2018. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0189-Restructuring-OnResetTimeout.md

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/556

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, Theresa Lech

Program Manager - Livio theresa@livio.io

[joeygrover]

• Would it make more sense that methodName is the FunctionID rather than a String?
• extensionPeriod naming and description seem odd. The name should imply that the value included will be the new timeout period, not how much the timeout is being extended.
• How will the UI and TTS component request to reset a timeout, ie, will it send both the BasicCommunication version and their respective specific versions? Does the HMI component negotiate versions with the Core component to know which it needs to send?

[atiwari9]

@joeygrover

Would it make more sense that methodName is the FunctionID rather than a String?

I thought so as well, but then current implementation for UI/TTS refer methodName String. It does make it better if functionId is referenced. Would there be a particular way to state it in XML or just Integer data type and updated description is sufficient?

extensionPeriod naming and description seem odd. The name should imply that the value included will be the new timeout period, not how much the timeout is being extended.

Agreed, i propose to change the param name to resetPeriod

How will the UI and TTS component request to reset a timeout, ie, will it send both the BasicCommunication version and their respective specific versions? Does the HMI component negotiate versions with the Core component to know which it needs to send?

Yes. Based on version, any new HMI implementation would just use the BasicCommunication version for UI and TTS. Any older HMI implementation could still utilize their respective versions for backwards compatibility. So it'd be an either/or scenario. Though there might be rare scenarios where HMI is updated w/o updating the core version itself.

[theresalech]

The Steering Committee voted to accept this proposal with the following revisions: extensionPeriod will be renamed to resetPeriod and the proposal will address that HMI Integration Guidelines will need to be updated to call out that there is not currently version negotiation between HMI and Core, so older HMI implementations will not work with this new version of Core.

Lastly, it was noted that details of deprecating an HMI API will be determined upon implementation.

[theresalech]

@atiwari9 please advise when a new PR has been entered to update the proposal to reflect the agreed upon revisions. I'll then merge the PR so the proposal is up to date, and enter issues in the respective repositories for implementation. Thanks!

[theresalech]

Proposal has been updated to reflect revisions. Issues have been entered: RPC Core Generic HMI SDL HMI