[Withdrawn] SDL 0313 - Adding new parameters for transport switching
theresalech opened this issue · 17 comments
Hello SDL community,
The review of "SDL 0313 - Adding new parameters for transport switching" begins now and runs through July 28, 2020. The proposal is available here:
Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:
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
1. Can you describe what iOS, JavaScript Suite, and Java Suite web apps devices are intended to do?
2. Can you provide additional information in the description on what data you expect to enter into vendorID, productID, and serialNumber from Android devices? You state elsewhere in the proposal that these are identifiers for USB, but the descriptions are not very useful right now.
3. I think it is important to note that the Android part of the Java Suite library already handles switching between transports when available. If one transport disconnects and another is available, the app will register on the still connected transport. This active switching has a much larger impact on the Java Suite code base than the proposal has provided. Please provide what transport and protocol layers would need to change in the Java Suite project to support this feature. I believe this will also have a fairly sizable impact on the router service as well.
USB connection is made with the same device. Then, the HU checks the newly connected USB information against the USB information acquired during BT connection.
When you mention the head unit (HU), is this behavior defined inside SDL Core, or handled by the rest of the HMI?
Since it is determined to be the same device, the HU performs the transport switching as SDL connection via USB.
Will this require any protocol level changes? It would be nice to have a flow chart showing the protocol and rpc messages sent during the switching process. The current SDL Core switching implementation relies on the iap transport, I don't think that will translate perfectly to the bluetooth and usb transports used in SDL Core.
- Are there any security risks that need to be addressed? There might need to be a secret ID that is created during the initial transports SDL connection. Maybe the hashID in the RegisterAppInterface request of the second transport should be required for the switch to take place. This would help verify it is the same app instance on a different transport.
@joeljfischer -san,
1.
It is assumed the means how to switch the connection to USB when launching an application (Navigation application etc.) that uses Video Streaming during BT connection.
2.
OK.
I will add the description and expected value of the adding parameters.
@joeygrover -san,
3.
Before our response, we would like to confirm about your comment?
Regarding "between transports when available", since it is not clarify the status of what is available, could you please provide the concrete example?
@JackLivio -san,
4.
We think that the same device judgement and transport switching will be greatly affected by the specifications on the OEM side, so consider it on the HMI side (excluding SDL Core).
5.
We think it is not necessary to change on the protocol level, because this proposal is only adding the parameters.
6.
We think there is no security risk about this proposal. Also, regarding the hashID, since our recognition is that the hashID is different for each transport connection even if it is the same app, so we think it is not necessary. Is our understanding correct?
-
Ok but I believe there are still changes that will be required within SDL Core's transport adapters to accomodate transport switching. There will need to be a way for the HMI to communicate to the BT and USB transport adapters that a switch is taking place.
-
Is there a more comprehensive flowchart of this feature that you could provide? Details that include:
- Messages from the HMI to Core and Core's transport adapters
- Protocol & RPC messages used during the switch
It is unclear to me if the app on the second transport goes through the normal connection/registration flow (start service & register app interface).
- The Hash ID could be transferable between transports as long as the mac address / device id was updated after the switch. See this application method used during the iap transport switch: https://github.com/smartdevicelink/sdl_core/blob/master/src/components/application_manager/src/application_impl.cc#L80
The Steering Committee voted to keep this proposal in review, to allow for more time to discuss the open items on the review issue.
3.
- IVI connects with Android device over bluetooth transport in SdlRotuerService
- App binds with router service and registers with IVI over bluetooth
- User plugs in USB cable and AOA connects to USB transport in SdlRouterService
- Application already bound with router service is notified that USB transport is available.
- User disconnects bluetooth
- App is unregistered because primary transport disconnected
- SDL library in application knows USB is still connected, so it will restart SDL in application
- Application registers again over USB as it is an acceptable primary transport
@joeljfischer -san,
2.
We will modify like below:
+ <param name="vendorID" type="Integer" minvalue="0" maxvalue="65535" mandatory="false">
+ <description> Vendor ID is a number of 4 digits or more assigned by each company issued by USB Implementers Forum</description>
+ </param>
+ <param name="productID" type="Integer" minvalue="0" maxvalue="65535" mandatory="false">
+ <description>Product ID is a number assigned by a company with a vendor ID so that it will not be duplicated for each product or model</description>@JackLivio -san,
5.
We are very sorry but there is no comprehensive flowchart for this proposal.
However, this proposal is related to SDL 0280.
Therefore, this flowchart is considered to be similar to SDL 0280's one.
Could you please confirm it.
@joeljfischer -san,
1.
#1058 (comment) is wrong. We are very sorry.
The correct is below:
It is assumed the means how to switch the connection to USB when the mobile device connects to the HU via USB during run an SDL app via BT connection.
@joeygrover -san,
3.
There are some method how to switch the transport. Such as priority, keep the first connection and etc.
The current specification what you say is to keep the first connection as much as possible.
However, there are some OEM to want to switch the transport more fast/stability/large capacity. By the reason above, we think it is necessary the means to switch the transport automatically.
@JackLivio -san,
4.
We recognize that the means of switch the transports is implemented in current SDL Core.
The HMI (OEM) can judge whether switch the transport.
By the request or notifivation from HMI, the SDL Core will switch the transport using the means same as current one.
Therefore, we think it is not necessary to the additional processing.
We confirmed the program code above and we understood to set only app_id, device_id and mac_address.
However, we could not understand the relationship to the hashID.
Could you please teach us the relationship of hashID and app_id/device_id/mac_address.
1. I'm not sure that this answers my question. I'm asking you to describe what the iOS, Java Suite, and JavaScript Suite should add into these fields, as well as how, if at all their startup flows should change.
2. I don't think that those are good parameter names then. I would suggest a change to USBVendorID and USBProductID
@joeljfischer -san
1.
We will talk about the correspondence internally.
We are having some confusing to respond. Could you tell us the reason of why you don't think these parameters good?
After further review and the author’s responses that lack the necessary details it is the project maintainer’s position that this proposal be rejected so that the author can rework the proposal to have better supporting information and a fully defined feature. There are three points the author should focus on:
- The proposal currently refers to a proposal that is not yet accepted as part of its solution and this not acceptable.
- The author should refer to the Multiple Transport Proposal. The proposal is a good template for how much information is necessary when creating these types of transport overhauls. The author should also note that it is specifically called out that the RPC and Hybrid services shall only run on the primary transport.
- The author should take note of how the current system works with primary and secondary transports and what services are available on which ones. The author should also take note in the actual code necessary in the app library projects that would be needed to support such a feature. Finally, since this feature intends to change how SDL sessions are handled between transports it is paramount that flow charts are included to describe how that happens as it will be something necessary to include in the protocol spec.
@joeygrover -san
I'm not disputing the rejection itself.
If the reviewer doesn't give us the reason of rejection, we're just asking for the reason, as we're having a hard time answering and looking ahead.
By the way, I am not saying that I will not present the flowchart because I will discuss how to create it internally.
( And, I think it's very ideal for authors to consider and suggest actual source code.
However, not all members have developers, so I think that there is a possibility that proposals will be suppressed if enforcement at the implementation level is forced.
I expect it to be resolved by separating the feature level discussion and the implementation level discussion. )
@joeljfischer -san
2.
Related to SDL 0280, SDL 0280 now defines parameters related to Bluetooth separately.
I think it is better to define USB separately as well.
I think @joeljfischer -san's opinion is that the parameter name should be made explicit, so I think it would be better to deal with the above as it is consistent with SDL 0280.
A little annoying is the handling of ”serialNumber”.
We plan to use "VendorID", "ProductID", and "serialNumber" to identify the Device(SmartPhone), but it is better to discuss whether to incorporate this into the USB parameter or leave it as is.
My previous comment points out a few reasons as to why we would move to reject the proposal and some points on how to address them. We are not trying to reject the idea of this feature, however, this proposal is simply inadequate to describe how that feature would work. We try to ask questions that will point the author in the right direction, but with the current state of this proposal it would take far too long to get those details worked out through comments. We believe the fastest way to accept this feature will be to reject this proposal and have the author rework it with additional details as described in my previous comment.
Regarding the inclusion of at least some implementation details, it is true that there is a risk to suppressing some proposals that do not include this information. Though that bar is necessary or else implementing a feature becomes far more difficult, and it’s a bar that every author must meet. That bar cannot change if an author doesn’t have adequate knowledge to write the proposal they want. The author must learn what is necessary to write a sufficient proposal or seek help in writing their proposal from those who have that knowledge. It’s an unfortunate limitation, but a necessary one since the author is usually the one who will have to implement the proposal as well and will therefore need all of that knowledge anyway. Scoping and reviewing those contributions becomes a much larger task as there is no way to anticipate what those changes will be.
As Joey-san says, I'm referring to an SDL-0280 proposal that hasn't been approved yet, so I think it's better to drop it from the review.
Once the SDL-0280 proposal policy has been finalized, we will change or add comments to the comments we have received, and request another review.
This proposal has been withdrawn per the author's request.