SDL 0206 - Remote Automated testing

[jordynmackool]

Hello SDL community,

The review of "SDL 0206 - Remote Automated testing" begins now and runs through January 15, 2019. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0206-remote_atf_testing.md

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

#633

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

[Jack-Byrne]

I like the idea but I think the proposal is missing details related to the transports supported by the Remote Adapter Server. Will the ATF remote server support web socket, pipe and mqueue connections?

[LuxoftAKutsan]

Open source implementation of Remote Adapter Server will support appropriate transports to test open source SDL : TCP for mobile connections (additional transports for automated testing provided in separate proposal), web socket for HMI connection. BTW, Remote Adapter Server is a components with listed transport agnostic interfaces, so for OEM it can be implemented for another transports, or API of Remote Adapter Server can be extended in case if OEM implementation of SDL requires any additional functionality.

[Jack-Byrne]

@LuxoftAKutsan Is the remote adapter server part of this proposal? What language is this program written in? If it is running on the target and communicating with the HMI then it should do so via web sockets at the very least since that is the only method of HMI communication used by SDL in the open.

[LuxoftAKutsan]

Yep remote adapter server part of this proposal, at least implementation for open source.
The best option of programming language is C++ to make supported platforms wide and latency minimal. It is running on the target, but it is not communicating with HMI, it communicate with SDL as HMI (using web socket for open source), also it controlled via ATF(from host) via TCP.

[Jack-Byrne]

What language is the Remote Client written in? What repositories are you proposing these components to be maintained in?

[Jack-Byrne]

For communication with SDL, the OEM adapter will need to implement this API. In case OEM requires additional functionality, relay server API may be extended.

Is this saying that this functionality won't be included in the implementation of this proposal and would need to be implemented separately by the OEM?

[LuxoftAKutsan]

Remote Client written in C++, it should be maintained in sdl_atf repository as part of ATF.
Remote Client should be reimplemened for OEM in case if OEM use another HMI communication transport, or have additional transports for communication with SDL.

[jordynmackool]

The Steering Committee voted to return this proposal for revision on 2018-12-11. The author is to include greater details related to the transports supported by the Remote Adapter Server as discussed in this comment and this comment.

[Jack-Byrne]

@LuxoftAKutsan

The Remote Client should be maintained in sdl_atf repository as part of ATF

What about the server? Will it be included in the ATF, SDL Core, or its own repository?

[LuxoftAKutsan]

@JackLivio both Client and Server shold be located in sdl_atf repository.

[jordynmackool]

The Steering Committee voted to fully accept this proposal on 2019-01-15.
An issue has been entered:
sdl_atf