See also: IRC log
<scribe> scribenick: ted
<scribe> scribe: Ted
Paul: last week we discussed where we are trying to go with these discussions
... the outcome is for the TF to come up with a recommendation to the WG for a next generation of specification
... it is more of a next round than a next generation
... last week PatrickB gave us a tour of their approach to media and how it compares to the various spotify, iheart, etc
... we previously stated the timeline of trying to have this ready before F2F
Ted: a proposal should focus on the broad strokes. the more technical granularities would be the scope of a rechartered WG. for signals we'll need to consider backwards compatibility
Fulup: there are some elements that can be used across interfaces such as authentication schema
... the lower level we try to go the harder it would be for normalization
... from an AGL point of view we need to go the full spectrum from lower level signals to developer applications
... same for music, weather, etc
... I have to propose something to AGL for this year's implementation
Rudi: as far as the signals are concerned there is W3C's VISS
Fulup: I presented this strategy to different people and not convinced I can get adoption
... whereas I see ViWi as easier
... problem will be big tree on the signals
Rudi: you can implement branches. it doesn't mean a vehicle has to expose all those signals
... ViWi is similar with end points
Fulup: I do not think that is an issue. we are not going to change how we handle signals but can map
Rudi: VISS has a pretty structured way of doing this, it is meant as a replacement to a fat API
... you do not want to have to constantly revise the specification when new signals are added. this allows them to move forward separately
... hopefully there will a core subset of signals that we will see widely exposed over time
... there will be signals that some oems will want to keep private
Fulup: we have separated high level and low level signal
Rudi: how the signals in the tree are handled by underlying system is up to implementers
... as far as moving foward we are continuing with VISS and need to discuss the next generation
... we have agreed on using web sockets for this version with discussion on the pros and cons of http or web sockets. the next version would likely be both
Fulup: ok with either transport. is there a reference implementation?
Rudi: I think four, Access, Mitsubishi, Inrix, ETRI+OCF
Paul: Inrix doesn't have an implementation
Fulup: any of them open source?
Paul: I think Peter's (Melco) is
[also I think Vin.li plans to, they demoed at Genivi CES showcase]
Paul: Newsky has one
Ted: done with Baidu
<Paul> https://github.com/newskysecurity/vswss
<Paul> https://github.com/PeterWinzell/vehicle-carsignal-examples
<Paul> https://github.com/aShinjiroUrata/vehicle-signal-server-spec/commits/master
Paul: I will work on a proposal along the lines of what Ted described, broad strokes
Adam: does this mean everything is back on the table including data model and auth mechanism?
<fulup-iotbzh> Shift of Luck look like no C/C++ reference implementation
Paul: I think so. Fulup had some input on security
Rudi: I hope it is more enhancing and extending than starting over completely
Paul: agree
[discussion of keeping the more technical specifics out of a general proposal for how to go forward. what to leverage from one, the other or an alternate approach would be in WG after general proposal is accepted]
[benefits of keeping signals' data model separate from the spec]
Fulup: you have variation in media as well
Rudi: we can agree on a higher level abstraction layer
Fulup: if you do not fulfill the media services' criteria for ip concerns you won't get the data (music)
Paul: I would like to see us to look at the next most useful domain, media and poi
... they may bring up additional security or digital rights issues
... access models should try to be similar
... I would like to see something like VISS or ViWi get adopted
... then when you know you are on a Genivi, AGL or other platform that implements it you know what is available
... we allow for extensions on signals
... this will allow app developers and integraters to operate independently
Rudi: let's tackle the next domains
... explore their use cases
Fulup: I need to know something works before I can propose it
Paul: by April we are suppose to have a Candidate Recommendation with test cases
https://www.w3.org/2014/automotive/charter-2016.html#deliverables
Fulup: I presented AGL's signal recently. we're pretty far along including test cases and benchmarking and that takes quite a bit of time
... we are going to continue monitoring this and may implement
... if any of the implementations were open source and in C then it would be easier
Ted: we do not require implementations be open source, only proof it is implementable by 2 parties along with a test case
... in AGL's case I think you wouldn't be able to take an implementation as is, you'll be doing more of a mapping
Rudi: it may be a little too early to look for a reference implementation
Paul: I agree it is desireable to know something will work before adopting
... we need to provide specifications, tests and encourage implementations
Rudi: let's use the wiki as the platform for drafting a proposal
PatrickB: we built our protocol first and as general as possible before designing the domains
... it would be good to get LG input on their implementation. not sure they are the same people at Birlingame who implemented
PatrickL: they are
Paul: I believe they are still part of the group
Ted: they are and we should encourage them to attend some calls
Paul: we should reach out to them
https://www.w3.org/community/autowebplatform/wiki/2g
Page for proposal. Anyone participating on these calls is welcome to contribute. We can see by revision history who suggested what