Automotive Working Group Teleconference

Location: https://lists.w3.org/Archives/Member/internal-autowebplatform/2017Mar/0005.html

(call coordinates)

<scribe> Meeting: RSI

Paul calls roll and introduces topic

Paul: notifications, media, location being domains we will focus on
... we may settle on another or additional times, a neutral name (other than ViWi), etc

Ted: call for participation, then settle on doodle for critical mass, maybe we will have to do 2 different timezone calls
... settle on a working name (RSI is good for now), repo dir (also rsi)
... Kevin might be interested in being an editor but can't speak for him. I'm reaching out to Samsung as I understand are others

Paul: LG is interested but couldn't make today

Gunnar: it sounds like there were some initial differences of opinion and wonder if we should try to separate the issues

Paul: we have done that
... it has gone in circles a bit. we have a submission that is worth exploring further
... this is in production automobiles
... we want to get broad participation on something useful for widespread adoption
... some of the hesitation was because we were already on a path

Gunnar: as you say vehicle signal spec is continuing and this is focusing on something else
... I don't think anyone is questioning whether this is viable

Paul: we have additional domains that we have been trying to get going for awhile now

Gunnar: I have not been part of that

Ted gives brief history on media and navigation and how neither are far enough along after considerable time

Gunnar: we want to avoid disparaged approaches for these different "domains"

PatrickL: we have not been able to open up navigation yet
... we started with the easiest to open, we have some internal difficulties to overcome

PatrickB: there were use cases on W3C wiki defined earlier, had someone I know working on a thesis come up with a clean room design
... it will differ from what we use at VW but will map well

Gunnar: it would have been beneficial to incorporate Genivi's approach

Paul: ultimately we want to align

Gunnar: all I am proposing is we look at viability of REST+socket as the protocol and then look at the domains
... I'm surprised location is on the proposed list

Paul: the point is to look at the submission and not ignore Genivi

Ted: we have an early draft from Qing An from Alibaba on LBS which has not received enough review. we have nothing submitted from Genivi nor anyone else on LBS at this point

Gunnar: we can work on a submission

Paul: in ViWi we have car, cdn, media library and media (services)
... we can look at the main protocol or a particular domain
... we are purposely not going into signals and letting that progress but looking at the other domains which have not evolved within the W3C BG to date

Gunnar: all I'm looking for is to find a way to work together to find the right APIs
... drawn from multiple sources
... from Genivi perspective we want to avoid having to redesign things

Rudi: my suggestion for moving forward is to separate the API from the transport/protocol
... examine APIs and see how we can present a high level API for application developers

PatrickB: I think you need the transport and associated principles with respect to statefulness etc defined before trying to work on a higher level API
... I started with the server side on github
... I started with some plugins for the service to be able to develop production software
... entire framework is implemented and a thin higher level API works
... as Gunnar illustrated, changing underlying infrastructure after the fact can be more complicated than taking it into consideration up front

+1

Gunnar: I don't think anyone disagrees with implementing and trying things out
... our theory within Genivi is essentially defining an API once and use across domains
... if you want to make an API perfect
... nobody is disagreeing
... we can try out areas we know we can likely all adopt the result, ones that would less likely be a problem

PatrickL: we don't really care which areas to try first. it would be nice to do something more challenging than simplistic, also something that would be more interesting
... location fits that bill, media is also of high demand
... if there is another domain you have in mind, please suggest it

Gunnar: location may be a good candidate

PatrickL: we feel there will be more changes for implementers than for media

Gunnar: we know how to do it on the vehicle signal side
... maybe REST and sockets are a decent approach and we can look at bringing our (Genivi) LBS with that model

Paul: are you discussing Genivi's IVI Navigation, POI, LBS Speech or?

https://at.projects.genivi.org/wiki/display/NAV/IVI+Navigation+Home

Sanjeev dropped link https://github.com/OAI/OpenAPI-Specification in WebEx

[review of 2G-VIS, circular discussions, common area]

Ted: the way the BG is structured, people can try new ideas even if they are competing

Paul: next steps? we have a mock server, start working in repo

PatrickB: next I need something interfacing with it
... further out someone can look at VLC api or something so they can do actual playback

Sanjeev: I can offer some developer time on clients

Gunnar: are people familiar with mpris? it is interesting for media APIs

https://specifications.freedesktop.org/mpris-spec/latest/

Gunnar: it is pretty widely used in Linux

Paul: call schedule?

Ted: I think weekly until AMM F2F

PatrickB: I'll look at mpris and expand the mock server and reach out to Sanjeev

PatrickB drops link to https://github.com/wzr1337/viwiServer

Sanjeev: we are working with VISS at OCF
... we are using a templating code based on swagger
... we are building out higher level APIs and spelling them out, they align well
... exploring more things through code and by next week I may more to share