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)

WoT Servient Architecture

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 ]