See also: IRC log
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
https://www.w3.org/community/autowebplatform/wiki/ViWi
[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
http://doodle.com/poll/4fwebn3qdu39hpsu#table
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]