[auto-wg] minutes - 16 Feb. 2016

available at:
  https://www.w3.org/2016/02/16-auto-minutes.html

also as text below.

Thanks,

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                             Automotive WG

16 Feb 2016

   [2]Agenda

      [2]
https://lists.w3.org/Archives/Member/member-automotive/2016Feb/0001.html

   See also: [3]IRC log

      [3] http://www.w3.org/2016/02/16-auto-irc

Attendees

   Present
          Paul_Boyes, Adam_Crofts, Dave_Jensen, Kevin_Gavigan,
          Junichi_Hashimoto, Kaz_Ashimura, Peter_Winzell,
          Shinjiro_Urata, Ted_Guild, Powell_Kinney, Song_Li

   Regrets
   Chair
          Paul

   Scribe
          kaz

Contents

     * [4]Topics
     * [5]Summary of Action Items
     * [6]Summary of Resolutions
     __________________________________________________________

   paul: we talked with TAG
   ... on Issue 72 refactoring
   ... one thing came up with the GENIVI call
   ... architectural pattern we agreeable
   ... logical architecture for that
   ... plugin-based and service-based
   ... LBS uses the same pattern
   ... any thoughts?

   <ted> Kevin and I are the only ones on so far it seems

   <ted> dial in worked

   dave: in favor of service-based approach

   paul: AdamC?

   hashimoto: no specific opinion

   kaz: don't have strong preference myself
   ... just wanted to mention the WoT group's work
   ... they're working on both the socket-based interface (WoT
   API)
   ... and the device-internal script interface (Script API)

   [7]WoT Servient Architecture

      [7] https://www.w3.org/2016/01/wot-f2f/wot-architecture.pdf

   peter: think service-based approach is promising

   powell: websocketty approach mentioned in the issue 72
   ... service-based approach is the right way to go

   urata: basically with the service-based approach
   ... but concerned with the possible schedule delay
   ... could someone clarify the good/bad points?

   paul: would leave it the group

   (lost audio...)

   kevin: @@@

   dave: makes sense
   ... the partial answer to Urata-san is that the current
   approach lacks flexibility
   ... we need to move to high level API

   ted: in favor of service-based approach
   ... to separate implementations from plugins
   ... for testing, etc.

   urata: I understand that choosing the websocket approach
   doesn't mean we don't need JavaScript APIs
   ... JavaScript APIs are useful for developers
   ... because easy to use

   paul: layered approach would be good
   ... service/websocket approach exposes the functionality using
   services
   ... how JS approach could work with it?
   ... the current API definition's expectation is working within
   the runtime

   dave: as a third party developer, would prefer simplicity
   ... easy enhancement

   peter: agree
   ... if you want to go more code completion function
   ... it's quite easy

   powell: @@@

   peter: also service-based approach makes the testing easy
   ... quite a few advantages

   urata: understand the good point that it would be easy
   ... not opposing the websocket approach
   ... just would like to clarify the situation
   ... we're using promise style APIs
   ... if we use the websocket approach, we can't use the promise
   style

   dave: can create promise style API by wrapping the low-level
   API

   kevin: can have high-level library
   ... high level representation

   dave: kind of like Node.js
   ... still have underlying HTTP server

   kevin: make sense but would loose advantage of high-level APIs
   ... OEMs would benefit with high-level spec

   dave: it's spec vs library

   paul: you want to have standardized vendor neutral APIs

   kevin: yes

   paul: the question is that in this specific group
   ... would it make sense to define the spec?
   ... focus on the value

   kevin: probably the low-level idea has attraction
   ... but as an implementer, it's complicated
   ... several signals responding to the real world
   ... signals treated separately
   ... we can correct the data together
   ... avility there

   dave: regarding the low-level approach
   ... depending on how low will you go
   ... APIs will be very simple if it's low-level enough
   ... the data spec itself could be tweaked to meet with the
   websocket approach

   paul: Kevin, make sense to you?

   kevin: would see pros/cons of the websocket approach

   dave: have created gist
   ... short brainstorm
   ... can open a new issue

   powell: happy to help out
   ... examples for better understanding

   paul: one thing useful is what discussed during the GENIVI call
   ... clarifying architecture pattern
   ... what goes to where
   ... as far as the timeline scope, this might impact the Charter

   ted: hopefully could fresh out quickly
   ... need to revise the Charter
   ... sounds like lean on the approach
   ... high-level API and low-level API
   ... competition anyhow
   ... developers may contribute on GitHub

   paul: to me, would like to do is getting a new issue
   ... what we need to do is getting consensus
   ... target architecture, strawman on what to decide
   ... anyone to volunteer?

   dave: can help the strawman

   peter: also would look into
   ... see the concrete work

   ted: would contribute

   kaz: can also help
   ... also think we might want to work for both the high-level
   API and the low-level API
   ... and see if the high-level API is implementable using the
   low-level API
   ... would be useful to define standard high-level interface
   (=standard implementation of the high-level API using the
   low-level API) for developers

   dave: conversation on pros/cons of the websocket approach
   ... strawman discussion
   ... high-level interface

   paul: architecture and high-level interface discussion

   dave: also data definition from WebIDL to JSON

   kevin: not objecting the vote on high-level vs low-level
   ... realistic implementers' security concern should be
   considered
   ... don't mind having both the high-level API and the low-level
   API

   dave: first action is strawman discussion on how the websocket
   approach works
   ... and the second architecture picture
   ... third is WebIDL to JSON
   ... fourth is existing high-level API can be implemented using
   the newly proposed low-level API

   paul: Urata-san, if you have specific opinions, please speak
   out

   urata: not sure how much time for this topic
   ... so need to talk within the company
   ... but would like to participate

   paul: good with this

   urata: about the service-based approach, the Generic Sensor API
   itself is not this type
   ... anybody aware of any spec which is really web-socketty?

   kaz: WoT IG is working on WoT API using socket level RESTful
   connection
   ... but they're still an IG, and would transition to a WG
   shortly
   ... Web&TV IG guys are also working to extend the web platform
   testing mechanism

   ted: TV Control API CG is working on API for TV tuners

   kaz: the v1 spec draft for TV Control API is device internal
   plugin style
   ... maybe they might want to think about websocket approach for
   the v2 version

   [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [8]scribe.perl version
    1.144 ([9]CVS log)
    $Date: 2016/02/16 19:13:06 $

      [8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [9] http://dev.w3.org/cvsweb/2002/scribe/



-- 
Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo
Tel: +81 3 3516 2504