Sdl_evolution: [Accepted with Revisions] SDL 0192 - Button Subscription response from HMI

Created on 1 Aug 2018  路  7Comments  路  Source: smartdevicelink/sdl_evolution

Hello SDL community,

The review of "SDL 0192 - Button Subscription response from HMI" begins now and runs through August 7, 2018. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0192-button_subscription_response_from_hmi.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/568

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
[email protected]

accepted with revisions core hmi

Most helpful comment

@joeljfischer , @mrapitis right the idea is to have the boolean parameter that will control subscribe or unsubscribe.
@JackLivio fo you mean that we should have following XML structure :

<function name="SubscribeButton" messagetype="request">
        <description>
            Subscribes to buttons.            
        </description>

        <param name="appID" type="Integer" mandatory="true">
            <description>The ID of the application requesting this button usubscription. </description>
        </param>

        <param name="buttonName" type="ButtonName" mandatory="true">
            <description>Name of the button to subscribe.</description>
        </param>
</function>

<function name="SubscribeButton" messagetype="response"> </function>

<function name="UnSubscribeButton" messagetype="request">
        <description>
            Unsubscribes from buttons.            
        </description>

        <param name="appID" type="Integer" mandatory="true">
            <description>The ID of the application requesting this button unsubscription. </description>
        </param>

        <param name="buttonName" type="ButtonName" mandatory="true">
            <description>Name of the button to unsubscribe.</description>
        </param>
    </function>

<function name="UnSubscribeButton" messagetype="response"></function>

All 7 comments

I believe this proposal is missing a detailed XML for the UnsubscribeButton RPC. I assume all these RPC changes are HMI_API changes.

Aside from the note that this is a major version change and may not occur for some time as a result, as well as my above note about missing detailed RPC information, I don't have an issue with this proposal.

@joeljfischer in this case the SubscribeButton RPC is actually used to subscribe or unsubscribe to a button. The subscribe parameter would be set to false to unsubscribe (making the UnsubscribeButton RPC unnecessary). Correct, these are HMI_API changes.

<param name="subscribe" type="Boolean" mandatory="true">
    <description>Flag to subscribe/unsubscribe to button presses. If true, the requester will be subscribed. If false, the requester will not be subscribed and be removed as a subscriber if it was previously subscribed.</description>
</param>

I generally like the method of using a subscribe parameter to subscribe/unsubscribe from an item but only when the subscribe parameter is in some sort of Get RPC. (GetInteriorVehicleDataRequest). Adding an RPC that has a subscribe parameter inside of a subscribe request would mean there are 3 styles that subscriptions happen in SDL.

Also The mobile API uses separate rpcs for subscribe and unsubscribe so this would be creating an additional discontinuity between the mobile api and hmi api when we have an opportunity to align the two API specs.

@joeljfischer , @mrapitis right the idea is to have the boolean parameter that will control subscribe or unsubscribe.
@JackLivio fo you mean that we should have following XML structure :

<function name="SubscribeButton" messagetype="request">
        <description>
            Subscribes to buttons.            
        </description>

        <param name="appID" type="Integer" mandatory="true">
            <description>The ID of the application requesting this button usubscription. </description>
        </param>

        <param name="buttonName" type="ButtonName" mandatory="true">
            <description>Name of the button to subscribe.</description>
        </param>
</function>

<function name="SubscribeButton" messagetype="response"> </function>

<function name="UnSubscribeButton" messagetype="request">
        <description>
            Unsubscribes from buttons.            
        </description>

        <param name="appID" type="Integer" mandatory="true">
            <description>The ID of the application requesting this button unsubscription. </description>
        </param>

        <param name="buttonName" type="ButtonName" mandatory="true">
            <description>Name of the button to unsubscribe.</description>
        </param>
    </function>

<function name="UnSubscribeButton" messagetype="response"></function>

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

  • Proposal will be updated to include the XML structure described in this comment
  • References to "UnSubscribe" within XML should be updated to "Unsubscribe".

@LuxoftAKutsan 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!

Proposal has been revised, and issues have been entered:
Core
SDL HMI
Generic HMI

Was this page helpful?
0 / 5 - 0 ratings