See also: IRC log
Agenda bashed, going to be hectic with various conflicts from Genivi sessions
[recap, dev progress, temperature of others]
Ted gives recap on state wrt VISS staying on track, focus on other "domains" and a public proof of concept
[ted has his phone connected to webex in case people join before speakerphone arrives]
RSI demo being setup
PatrickB starts intro presentation
[repeat of Burlingame, see 2016-10-20 & 21 minutes with link to slides]
https://www.w3.org/2016/10/20-21-auto-member-minutes
[another copy of slides sent to member-automotive@w3.org]
https://lists.w3.org/Archives/Member/member-automotive/2017May/0015.html
PatrickB: decision to focus on HTTP so as to be able to allow phones to connect via BT
Wonsuk: based on BT standard?
PatrickL: BT + serial port profile since it is the most stable
Wonsuk: usual pairing and a follow up step?
PatrickB: install app on phone, pair with BT as usual, then second permission for the phone
PatrickL: yes you then allow the device to access the apis from the head unit
PatrickB: after that reconnects are automatic
PatrickL: preshared key
... that installation of that application on that phone is
paired with that car
Ted: you can pair with more than one car?
PatrickL: yes
... TLS protecting the device / car interactions
... I would like to discuss standardization of the tokens and
pairing
Ted: I should ask colleagues, Dom in particular
PatrickB: we presented this to
the group in October, joined W3C and made a Member
Submission
... other domains pending
... we are working on demo server for media at present
<PatrickLue> Java RSI Client Implementation: https://github.com/luennemann/RSIMedia
PatrickB: we have 5-6 contributors already on github
<PatrickLue> + Media Client
PatrickB: VW has this in production vehicles, initially a modest number of cars with intent of widening it to other models in the coming year
https://www.w3.org/Submission/2016/01/
protocol, cdn, media (services), media library, mixer
additional pending: notifications (likely), navigation (more difficult)
[additional history summary for Lovene's benefit]
Paul: Philippe Colliot (PSA) hopefully can join us today or tomorrow
Ted: we also have work from Qing An Alibaba around LBS plus Genivi hopefully can fill in on nav
PatrickL: navigation is also incredibly complicated
(order of statements out of sync)
PatrickB: talking to eg Spotify
they do not want to write something for a measely 10M cars when
they are focused on billions of other devices
... they would be willing to write the bridge
(earlier Ted noted iHeart said they find ViWi/RSI media workable for them)
Ted: it is just a thin wrapper around their proprietary API
PatrickB: if they are not willing
to write that wrapper we can
... auto industry is very fragmented. some of these content
providers have done one off solutions and have found it painful
including the long term contracted maintenance commitment
Peter: Spotify did it once for
WindowsCE and understand that was painful as well
... I agree with the statement of the problem
PatrickL: we want to have something easily usable by content providers to be in another ecosystem similar to Apple carplay and Android auto
<scribe> [pending additional domain explained off the record]
Wonsuk mentions a similar effort at W3C for this other domain
PatrickL contrasts, mostly on user interaction
VW's additional submission is based on existing convention (quasi-standard)
[ted prepares to depart for Genivi panel, group will continue on RSI or possibly VIAS]
<peterw> == peterw taking notes on irc
<peterw2> == Patrick the RESTFULness very important for the RSI approach
<paul> RSI has graph interface
<paul> like FB
<peterw2> Restfulness supports microservices architecture
<peterw2> patrick guidelines to obtain tokens needed
<paul> http://wamp-proto.org/
<paul> http://openid.net/connect/
<peterw3> paul DLNA for media
<peterw3> == RSI approach high level business drivn
<paul> https://wiki.openmobilealliance.org/display/OI/OMA+Report+on+Automotive+Opportunity
<paul> https://wiki.openmobilealliance.org/display/OI/OMA+Report+on+Automotive+Opportunity
<paul> IoT architectures are somewhat similar
PatrickL: what does the group think should be the next step towards standardizing the protocol
... we are trying to bring use cases into our regular calls, show it works, make it open source so people can try it out
Ted explains BG process and reports, suggests next step
Paul: it is difficult to get participation, people are too busy with their day jobs
... I also want to avoid fracturing such a small group
... people can start playing with the mock server and creating their own. we should do some outreaach, involve people like Roger
Ted: another advantage to getting this going in the BG is lower barrier of entry, legally and financially
Bernard: you guys need to be better about messaging, updating the BG page where people land and want to learn what is going on
Ted: I am guilty of not being able to put in enough time in that due to my other day job at W3C (Head of Systems) and also not the best at messaging
... people from this group (or their organizations) are more than welcome to contribute to blog articles, news feeds etc. I will try to be better
Paul: we are revitalizing what is taking place in the BG
... let's agree on a name and get going
PatrickL: define the name, put on github, encourage people to join
Paul: using repec
... I would like to see what JLR's interest is here. You have been heavily involved in W3C VISS and VSS
Kevin: generally supportive
Adam: similar model to web sockets
Kevin: nothing has changed in our commitment to the group
Paul: one problem has been the time of the meeting
PatrickB: we should try to have more public discussions
... benefit is more promotion, suggest #w3cauto
<auto> Schedule meeting to work for all
<auto> Move specs to respec
<auto> put more info on website
<auto> make effort to publicize
[discussion on specific organizations we would like to engage, history of pass participants]
PatrickL: I want to understand the issues you are facing
Adam: if for example you don't include the path in getVSS method you get the entire tree
... what we wanted to do is perhaps emit path but what to do if you're given null
... do we feel having WebIDL and JSON schema in the same spec is a good idea?
Wonsuk: if there is no path property that could mean the client wants the whole vss tree
... in webidl there is no null option
Adam: saying filters=null is the issue
Ted: isn't filterrs optional?
Adam: yes but either we stick with webidl or do not. webidl is for interacting with an api within the browser, whereas here we're talking to a service
Peter: i don't want to check json objects for path sometimes but not others
https://github.com/w3c/automotive/issues/174
Ted: problem arises since we're trying to use WebIDL for a service
Paul: what are the reasons for sticking with it?
Ted: perhaps for easier binding to VIAS
Adam: I don't think that is relevant
Ted: then it is simply influenced by tooling (respec) and consistency with other w3c spec patterns
[discussion of dropping webidl since we are not doing an ecmascript api]
Ted consults Philippe Le Hegaret via irc
https://www.w3.org/TR/webdriver/
ok to drop webidl, will confer also with Mike Smith
plh suggests, correctly, we are perhaps misusing webidl and can cause ourselves problem in the future
tentative resolution: ditch webidl and see if Ted can get suggestions from Mike or others
web driver was given as a possibly pertinent examplep
[back to filters]
PatrickL: I would be inclned to have two interfaces insteaad of this compound one
... separating getVSS and filter
Adam: interesting, thanks that might solve some other issues
PatrickL: document for the data structure again?
PatrickL: any experience generating C++ object model from YAML?
Paul: the fidl view might be helpful, Urata might have done something too
Urata: to csv
Paul: Franca people would be familiar, try Gunnar since you don't know Klaus
PatrickL: I like the documentation in YAML
Wonsuk points out VSS parser which is extensible
PatrickL: that is pretty powerful and documentation in the core truth (YAML). I could see taking JSON or another form to build out a mock server automatically
Lovene: would you be able to open your tooling as well?
PatrickL: possibly including adding to the VSS parser
... I need JSON for some of my purposes
Paul: reason for YAML was to go lower in stack to C++ and Franca
https://github.com/w3c/automotive/issues/200
time to live (ttl) in milliseconds (ms) in our spec, usually this is represented in seconds
Resolved: group agreement for ttl to be in seconds
https://github.com/w3c/automotive/issues/142
Adam: we should be able to set lock for everything within door via wildcard, no concern of number of doors nor look at vss beforehand
Ted: 409 Conflict could work fine here especially to be consistent with rest of spec. alternates for door not being closed example 412 Precondition Failed 416 Requested Range Not Satisfiable or 417 Expectation Failed
Urata: in the explicit example, iterating through doors, the server has to try each interaction separately
... you can have separate response codes and consider the overall failed if any fails
PatrickB: yes but perhaps rollback state for the others
Kevin: you might want to leave the lockable doors locked
PatrickB: 202 accepted could signify partial success instead of 200 OK for all
... or other in 2NN range
Adam: we don't give 200s since we're not REST at present
Kevin: success is JSON fragment or failure response
Ted: ideal would be to know which failed but that would complicate the failed response
PatrickB: we tend to send back a 200 for ok, 400 for client side and 500 if issue is with ECU
<junichi-hashimoto> how about simply to prohibit "wildcard set"?
Kevin: on failure, partial or full, you would need to iterate to find state of each
Junichi: you can end up in a deadlock state especially if multiple clients are interacting. I would prefer to keep it simple
PatrickB: you have to queue requests to be able to process them separately
... last wins
Kevin: that is problematic when it isn't a binary true/false but incremental change
<junichi-hashimoto> fyi, once we investigated 'set' method. there may be more complicated race conditions https://w3c.github.io/automotive/vehicle_data/security/#set-set-method