[Accepted] SDL 0063 - Display name parameter

[theresalech]

Hello SDL community,

The review of "Display name parameter" begins now and runs through May 23, 2017. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0063-display-name-parameter.md

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

#184

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

[joeljfischer]

This appears to be a minor version change.

[Toyota-Sbetts]

This was discussed previously between Toyota, Ford, Livio and Xevo and an issue to add a generic display type was previously opened:
smartdevicelink/sdl_core#626

We don't really have a concern with depreciating "displayType" but what is the general benefit of adding an unenumerated "displayName"?
As discussed in the issue, we feel it's important to have a way to inform applications of the more detailed display capabilities like display type (text vs video), resolution, etc. which should be expanded in another proposal.
DisplayName could be included here but alone we don't see it as a very helpful parameter and requires the application to be aware of unique or new names if it wants to utilize it.

[joeljfischer]

@Toyota-Sbetts I was thinking the same thing. The only thing I could think of was to combine it with the Make/Model and the system software version / SDL version so that the app could use analytics and know what displays are commonly used with their app. Otherwise, I don't see a need for it.

[Toyota-Sbetts]

@joelfischer Analytics are a good point and I could see that use but I think the different combinations of make/model/model year/trim/etc is enough information to generate quite a few unique identifiers especially if we add additional display capabilities like screen size/type/resolution.

I think if we're going to leave it unenumerated we need to define the structure/intent of the string that is sent similar to the locale proposal. Otherwise we may have HMIs implementing vastly different behaviors (some might send the user settable system name, some might hardcode it, different regions or vehicles might use the same name). That's a lot for the app developer to be aware of.

[joeljfischer]

@Toyota-Sbetts That's a good point. It would have to be defined much better than it currently is if it were to be in use. I agree with you that the displayName parameter should be removed.

[theresalech]

This proposal has been accepted by the Steering Committee. After much discussion about the displayName parameter, it was decided that the parameter should be kept as there are specific use cases where the parameter is helpful for OEMs, notably OEM-created apps. In the future, we may want to have the displayNames for certified head units recorded publicly for reference.

[theresalech]

Issues entered:
Core
iOS
Android
RPC
SDL HMI