[Accepted] SDL 0042 - SDL must transfer RPC’s with invalid image reference parameters to the HMI about sdl_evolution HOT 13 CLOSED

One additional benefit not explicitly stated in the proposal is that an app could actually post load images. An RPC request like a show command could be sent with a reference to an image that would be loaded onto the file system later. After the image is successfully pushed to the file system, the HMI could be notified of the putfiles existence and update the display as needed.

If possible, I think this would be a very worthwhile addition to this proposal.

from sdl_evolution.

@mrapitis
How're you?
I'm MASASHI and an engineer from SUZUKI.

There are some questions as below.
Could you explain that, if you don't mind?

1. What is the difference between "image" and "Image" in this proposal?
2. Not easy to imagine that "RPCs include an invalid Image reference"
   Could you give me examples or explain more in detail?

from sdl_evolution.

Hi @ISHIZAKI-MASASHI,

Thanks for your feedback. Please find my response below. Thanks!

• The references to image and Image actually have the same meaning. The parameter of type 'Image' is the specific type in our mobile api specification (linked below). Informally the parameter is referenced as an image type.

https://github.com/smartdevicelink/sdl_core/blob/master/src/components/interfaces/MOBILE_API.xml#L808-L815

• Currently if an RPC such as a show command makes a reference to an image that does not exist on the system for any reason, the image reference is considered invalid and the RPC will receive and invalid data response. This proposal adds the capability for sdl to continue processing the RPC and warn the HMI that the image being referenced by the RPC does not exist on the system. The HMI can then gracefully handle the request.

from sdl_evolution.

Is the problem being addressed significant enough to warrant a change to SDL?

This doesn't seem like a huge problem, but worth solving.

Does this proposal fit well with the feel and direction of SDL?

I think both this solution and the alternative are plausible solutions.

If you have used competitors with a similar feature, how do you feel that this proposal compares to those?

N/A

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading

Please state explicitly whether you believe that the proposal should be accepted into SDL.

I believe this proposal should be accepted.

from sdl_evolution.

Here are my concerns with this proposal:

• the definition of proposal makes sense; although the benefit of a somewhat different behavior doesn't seem to be clear. Aren't we just changing the system's response to a bug in a mobile application?

• I fully agree with the potential downsides:

Since RPC's with invalid image references are processed successfully, the mobile app may be less likely to resolve logical errors in image processing.

• I could go almost either way with this proposal. Both the current definition of behavior and the proposed one make sense. Considering the somewhat limited benefit, however, I'd prefer not to change existing behavior.

from sdl_evolution.

@mfoedisch thanks again for your feedback.
One additional benefit not explicitly stated in the proposal is that an app could actually post load images. An RPC request like a show command could be sent with a reference to an image that would be loaded onto the file system later. After the image is successfully pushed to the file system, the HMI could be notified of the putfiles existence and update the display as needed.

from sdl_evolution.

@mrapitis
Thank you for reply.

Could you tell me if my understandig is wrong?
■my understanding
Mobile app sends an RPC with an invalid image to SDL Core (which is in Head Unit?)
SDL Core validates the image parameter whether or not in the "AppStorageFolder".
The HMI judges how to respond to an RPC throgh SDL Core.

Here are questions as below again.
Please answer these questions.

1. Who has the "AppStorageFolder"? SDL Core? HMI? or other?
2. If you want the HMI to judge to respond to an RPC with the invalid image, should the HMI have the "AppStorageFolder" or not? Access limitation is necessary or not?

from sdl_evolution.

@ISHIZAKI-MASASHI Please find response below. Thanks!

Who has the "AppStorageFolder"? SDL Core? HMI? or other?

• The AppStorageFolder should be available to both SDL Core and the HMI. SDL Core will typically put a file in the AppStorageFolder at the request of the mobile application. The HMI can then be notified that a file is available for its usage in the filesystem.

If you want the HMI to judge to respond to an RPC with the invalid image, should the HMI have the "AppStorageFolder" or not? Access limitation is necessary or not?

• The HMI shouldn't be limited as far as accessing the AppStorageFolder. This proposal allows for the rpc to still be processed successfully (with warnings) even if the file is not (yet) available.

from sdl_evolution.

This is a proposal we had also been considering raising and we support it. While if the app is using Putfile, ListFiles and Show correctly they may not have an issue, it can be difficult for an app developer to figure out why an RPC is failing or handle all edge cases in the app logic. As developers start using their apps on more HMIs that will have different policies, this change will allow HMI's to at least handle the valid data passed in the RPC instead of nothing at all.

from sdl_evolution.

One additional benefit not explicitly stated in the proposal is that an app could actually post load images. An RPC request like a show command could be sent with a reference to an image that would be loaded onto the file system later. After the image is successfully pushed to the file system, the HMI could be notified of the putfiles existence and update the display as needed.
If possible, I think this would be a very worthwhile addition to this proposal.

We will need to append one addition to this proposal to allow the putfile to notify the HMI as currently it is only notified for a 'systemFile'

https://github.com/smartdevicelink/sdl_core/blob/master/src/components/interfaces/HMI_API.xml#L2398-#L2401

from sdl_evolution.

I fully support this proposal. Image post loading would be an excellent addition. It would be extremely helpful for choices and manual interactions.

from sdl_evolution.

The Steering Committee has agreed to accept this proposal. They also recommended that an additional proposal be submitted for the additional post loading of content.

from sdl_evolution.

Issues entered:
Core
SDL HMI
Generic HMI

from sdl_evolution.