Automotive Working Group Teleconference

06 Feb 2017


See also: IRC log


Adam, Paul, Hira, Ted, PatrickL, PatrickB, Kevin


Paul: trying to organize these calls more
... given some limitations on screen sharing from Linux we resolved to try to have materials shared in advance
... Patrick or Patrick will present a comparison

-> https://lists.w3.org/Archives/Member/internal-autowebplatform/2017Feb/0003.html Comparison exercise

PatrickL: some types of developers aren't keen at looking at documentation, in automotive they generally are but we'll be attractive other types
... in viwi you can get all available with a GET of /car or GET of /car/door
... going the exploration instead of documenation approach you'll need to do two calls to find the doors
... to get a list of all open doors you can ask GET /car/doors/?isDoorOpen=true
... in viss to get a list of all doors that are open it seems you have to get all door data and iterate over them
... assuming you could close a door through these interfaces you would do a POST in both examples (set for viss)

[[POST /car/doors/<id of your door>

{ isDoorOpen: false }]]

in viwi

[[SET doors.<your door>.isLocked: true]]

in viss

PatrickL: I understand filtering for subscriptions but not for get

(in viss)

PatrickB: filtering can be very handy for media for example (when you have extensive audio files available)

Kevin: is this an action to add filtering on viss get?

Paul: this isn't a WG call, no changes are being asked

PatrickL: we might find things that are desireable to implement as a result of these discussions, we're just reviewing differences

Paul: it might be best to collect these on a wiki


[ted will rename the wiki to the name Rudi came up with 2G-VIS]

Ted: people are welcome to create additional pages or use this one and i'll likely rename this one and redirect it

PatrickL: Kevin, do you feel this sort of comparision is helpful or do you have a different suggestion?

Kevin: it makes sense. my concern is we want to avoid going back to square one with AGL or PSA...

Paul: Justin Park did a comparison of 5-6 different specs, focused mostly on signal level and find the core set of things that are useful
... you might want to take high level differences and different paradigms and bindings
... cataloging helps the discussion

Kevin: viwi handles additional things like we've been discussing like media
... I may shameless steal the idea of filtering on get for viss and adding that as an issue

PatrickL: we can do additional comparisons, wonder how helpful they will be

<KevG> Consensus item - Consider adding filtering to get (as implemented in VIWI) - added as issue 135

<KevG> Consensus item> Consider adding filtering to Set e.g. to set a subset of doors so that isLocked=true #136

Ted: the biggest difference is sockets vs http rest+sockets. we dropped http before in interest of time and because we felt we had what we needed from sockets. that is probably worth looking into further

Kevin: are you doing filtering on set (POST) in viwi?

PatrickB: it is possible
... the idea was to have http querystring that would restrict results as if it were a sql select
... you can similarly have a POST that sends a lock request on all unlocked doors instead of all doors based on querystring

Kevin: that is rather neat

PatrickB: you can similarly subscribe based on query parameters

Ted: I'm wondering if you can filter on attribute level on viss, think you can

Adam: yes, you can identify an attribute value you're interested in and subscribe to them

<paul> https://github.com/w3c/automotive/issues/136

<paul> https://github.com/w3c/automotive/issues/135

[comparison on screen share of trying to do a selective set/post based on attributes]

PatrickB: you can easily use both notations, CSS of VISS, or REST of ViWi
... we should bear in mind others' approach outside of automotive since we will be bringing them together in the same space

Kevin: do you see viwi wrapping around audibles, pandora etc? data will be downloaded from those services but then they would be available to app developer on head unit?

PatrickB: yes and no, some you won't wrap and just have eg spotify available as an api in a similar manner
... depends on the service you want to address. some are aggregrated from multiple sources
... viwi api can provide links to songs you want to play back that are in your library but you can't get a link to spotify song

PatrickL: disclaimer Audi is doing things different than rest of VW group at present
... assuming content providers are subscribed to and available on a head unit, you'll have a way to get to them from viwi
... I started to compile a list of possible comparisons in wiki

Paul: speaking from OpenCar point of view, I have seen various OEM SDKs and appreciate the abstraction layer and not have to integrate on a lower level
... we are not talking one size fits all here
... it can be helpful to see how sockets compare to rest to APIs/SDKs
... I'm willing to put together some notes from my experiences on the wiki
... people will come at this from different perspectives

PatrickL: it would help me to understand why this approach went sockets only

Paul: perhaps Adam or Kevin can help put something together for that. it was a group decision earlier

Adam: I think it boils down to we saw we had enough of what we need from sockets alone

PatrickB: I'll prepare some arguments for REST


Every [other] Monday 2100 PST / 0600 CET / 1400 JST

[discussion on alternate time that is more friendly to Asia. Ted will setup WebEx for alternate time]

<paul> https://www.genivi.org/events

<paul> https://www.automotivelinux.org/news/events

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/02/06 22:16:34 $