[Withdrawn] SDL 0330 - App Service Subscription Resumption
jordynmackool opened this issue · 8 comments
Hello SDL community,
The review of "SDL 0330 - App Service Subscription Resumption" began on February 09, 2021, and continues through February 16, 2021. 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,
Jordyn Mackool
Program Manager - Livio
Jordyn@livio.io
1.Sorry to trouble you, but is it possible to provide a sequence diagram of the process, etc. in order to make it easier to understand the contents described in the proposed solution?
- I will create some flowcharts to help the readability of the proposal.
The Steering Committee voted to keep this proposal in review on 2021-02-09 to allow the conversation to continue on the open item.
2. Are requirements 1-6 really helpful? Most resumption situations are in order to prevent major processing flows (like VR) from needing to be accomplished again. I don't see that as necessary here, and I think this use-case is too complicated. Too many things may have changed since the app was last connected (such as a phone being unplugged), and the "help" being given here is too slight (subscribing to the active provider is fairly fast), that I don't see that it's necessary to resume app service subscriptions at all.
In fact, I think that this proposal may be actively harmful by adding quite a bit of complexity to the app without much gain. Currently, when an app connects, it needs to check what it wants to subscribe to and subscribe. This proposal adds a new flow where the app may be re-subscribed to services that it no longer wants to be subscribed to, therefore adding new flows where the app needs to see what was resumed, un-subscribe, then subscribe to what it actually wants to be subscribed to. I think that this proposal will be a significant source of bugs for apps that will lead to apps, when they connect, unsubscribing from everything that was resumed and subscribing to what they want, which defeats the whole purpose of this proposal.
The same thing happens for app publishers. This adds additional complexity and flows for them to need to handle with little gain.
If the author and SDLC still wants to go forward with this proposal as-is, I would oppose it, but request several changes: (1) add additional downsides describing the added complexity for apps, (2) add example app code describing how an app would have to handle all of these changes, (3) add additional callbacks for the app to know what is now subscribed and what is not at the time of resumption since it seems rather indeterminate.
4. Requirement 7 seems helpful to me. I think this proposal could be re-written to only encompass this change.
- Intention of the proposal was to define some base behavior for app services during resumption since all other SDL core subscriptions have a defined behavior for success vs error cases. This proposal is essentially to fill in the app services gap that was not mentioned in these implemented proposals:
- https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0190-resumption-data-error-handling.md
- https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0188-get-interior-data-resumption.md
I can try to defend the usefulness of each requirement but is there a point to dragging this out when the initial receptiveness of all requirements is labeled as "actively harmful"?
- Requirement number 7 fixes a borderline a bug and should definitely be addressed (it doesnt really have to do with resumption either). I can submit it as its own proposal so it does not get caught up with the complexities caused by the other requirements.
edited wording for number 4*
2. I'm approaching this from the app developer perspective. The app services subscription model is much more complex than remote control or vehicle data. Because the resumption process is so variable as you laid out, from the app developer perspective I would rather not have this feature than to have to write code to account for it. It's easier to start from nothing, figure out what I want to subscribe to, and subscribe, than to start subscribed to some things, figure out if I still want them, etc. as I previously laid out.
Personally, I'm not sure how helpful vehicle data / remote control subscription resumptions are since they're easy to re-subscribe to, but because they're relatively stable (the only changes I could think of would be permissions to now disallow something you were subscribed to), they're much easier to handle a resumption flow on the app developer side.
@jordynmackool I would like to withdraw this proposal. The minor optimizations are likely not worth the added complexity this would cause.
The Steering Committee voted on 2021-02-16 to withdraw this proposal based on the author's request to do so in this comment.