17:30:53 RRSAgent has joined #auto 17:30:53 logging to http://www.w3.org/2016/02/16-auto-irc 17:30:57 urata_access has joined #auto 17:31:17 Meeting: Automotive WG 17:31:33 agenda: https://lists.w3.org/Archives/Member/member-automotive/2016Feb/0001.html 17:31:52 junichi_hashimoto has joined #auto 17:32:33 AdamC has joined #auto 17:36:08 Is the meeting id 383-455-661, thanks 17:37:18 thanks Kaz 17:39:21 present+ Paul_Boyes, Adam_Crofts, Dave_Jensen, Kevin_Gavigan, Junichi_Hashimoto, Kaz_Ashimura, Peter_Winzell, Shinjiro_Urata 17:39:47 present+ Ted_Guild 17:40:32 paul: we talked with TAG 17:40:39 ... on Issue 72 refactoring 17:41:06 ... one thing came up with the GENIVI call 17:41:21 ... architectural pattern we agreeable 17:41:34 ... logical architecture for that 17:41:48 ... plugin-based and socket-based 17:41:55 s/socket/service/ 17:42:05 ... LBS uses the same pattern 17:42:09 ... any thoughts? 17:42:30 Kevin and I are the only ones on so far it seems 17:42:38 dial in worked 17:42:42 dave: in favor of service-based approach 17:43:23 paul: AdamC? 17:43:25 djensen47 has joined #auto 17:43:45 hashimoto: no specific opinion 17:44:59 kaz: don't have strong preference myself 17:45:07 ... just wanted to mention the WoT group's work 17:45:10 ... @@@ 17:45:26 peter: think service-based approach is promising 17:46:11 powell: websocketty approach mentioned in the issue 72 17:46:28 ... service-based approach is the right way to go 17:47:11 urata: basically with the service-based approach 17:47:31 ... but concerned with the possible schedule delay 17:47:46 ... could someone clarify the good/bad points? 17:48:28 paul: would leave it the group 17:49:21 (lost audio...) 17:49:44 kevin: @@@ 17:49:52 dave: makes sense 17:50:45 ... the partial answer to Urata-san is that the current approach lacks @@@ 17:50:54 ... we need to move to high level API 17:51:41 ted: in favor of service-based approach 17:52:02 ... to separate implementations from plugins 17:52:06 ... for testing, etc. 17:52:46 urata: I understand that choosing the websocket approach doesn't mean we don't need JavaScript APIs 17:53:03 ... JavaScript APIs are useful for developers 17:53:09 ... because easy to use 17:53:22 paul: layered approach would be good 17:53:54 ... service/websocket approach exposes the functionality using services 17:54:15 ... how JS approach could work with it 17:54:21 s/it/it?/ 17:54:48 ... the current API definition's expectation is working within the runtime 17:56:05 dave: as a third party developer, would prefer simplicity 17:56:22 ... easy enhancement 17:56:28 peter: agree 17:56:59 ... if you want to go more code completion function 17:57:05 ... it's quite easy 17:57:53 powell: @@@ 17:58:07 peter: also service-based approach makes the testing easy 17:58:21 ... quite a few advantages 17:58:38 urata: understand the good point that it would be easy 17:58:48 ... not opposing the websocket approach 17:58:55 ... just would like to clarify the situation 17:59:11 ... we're using promise style APIs 17:59:29 ... if we use the websocket approach, we can't use the promise style 17:59:54 dave: can create promise style API by wrapping the low-level API 18:01:03 kevin: can have high-level library 18:01:21 ... high level representation 18:01:36 dave: kind of like Node.js 18:02:05 ... have still underlying HTTP server 18:02:13 s/have/ 18:02:21 s/still/still have/ 18:03:06 kevin: make sense but would loose advantage of high-level APIs 18:03:23 ... OEMs would benefit with high-level spec 18:04:02 dave: it's spec vs library 18:04:53 paul: you want to have standardized vendor neutral APIs 18:04:56 kevin: yes 18:05:12 paul: the question is that in this specific group 18:05:22 ... would it make sense to define the spec? 18:05:35 q+ 18:05:48 ... focus on the value 18:06:09 kevin: probably the low-level idea has attraction 18:06:21 ... but as an implementer, it's complicated 18:06:37 ... several signals responding to the real world 18:06:46 ... signals treated separately 18:06:55 ... we can correct the data together 18:07:05 ... avility there 18:07:18 present+ Powell_Kinney, Song_Li 18:07:29 dave: regarding the low-level approach 18:07:41 ... depending on how low will you go 18:08:00 ... APIs will be very simple if it's low-level enough 18:10:12 ... the data spec itself could be tweaked to meet with the websocket approach 18:10:38 paul: Kevin, make sense to you? 18:11:39 kevin: would see pros/cons of the websocket approach 18:12:06 dave: have created gist 18:12:22 ... short brainstorm 18:12:29 ... can open a new issue 18:12:38 powell: happy to help out 18:12:49 ... examples for better understanding 18:13:27 paul: one thing useful is what discussed during the GENIVI call 18:13:36 ... clarifying architecture pattern 18:13:44 ... what goes to where 18:14:02 ... as far as the timeline scope, this might impact the Charter 18:14:54 ted: hopefully could fresh out quickly 18:15:17 ... need to revise the Charter 18:15:48 ... sounds like lean on the approach 18:16:14 ... high-level API and low-level API 18:16:29 ... competition anyhow 18:16:49 ... developers may contribute on GitHub 18:17:39 paul: to me, would like to do is getting a new issue 18:17:50 ... what we need to do is getting consensus 18:18:11 ... target architecture, strawman on what to decide 18:18:21 ... anyone to volunteer? 18:18:43 dave: can help the strawman 18:18:58 peter: also would look into 18:19:19 ... see the concrete work 18:19:27 ted: would contribute 18:19:43 kaz: can also help 18:21:00 ... @@@k 18:21:23 dave: conversation on pros/cons of the websocket approach 18:21:32 ... strawman discussion 18:21:45 ... high-level interface 18:22:02 paul: architecture and high-level interface discussion 18:22:24 dave: also data definition from WebIDL to JSON 18:23:39 kevin: not objecting the vote on high-level vs low-level 18:24:05 ... realistic implementers' security concern should be considered 18:24:36 ... don't mind having both 18:25:06 s/both/both the high-level API and the low-level API/ 18:25:26 dave: first action is strawman discussion on how the websocket approach works 18:25:36 ... and the second architecture picture 18:25:51 ... third is WebIDL to JSON 18:26:28 ... forth is existing high-level API can be implemented using the newly proposed low-level API 18:26:35 s/forth/fourth/ 18:27:43 paul: Urata-san, if you have specific opinions, please speak out 18:27:56 urata: not sure how much time for this topic 18:28:05 ... so need to talk within the company 18:28:12 ... but would like to participate 18:28:22 paul: good with this 18:29:05 urata: about the service-based approach, the Generic Sensor API itself is not this type 18:29:28 ... anybody aware of any spec which is really web-socketty? 18:31:22 kaz: WoT IG is working on WoT API using socket level RESTful connection 18:32:59 ... but they're still an IG, and would transition to a WG shortly 18:33:36 ... Web&TV IG guys are also working to extend the web platform testing mechanism 18:34:13 ted: TV Control API CG is working on API for TV tuners 18:34:36 kaz: the v1 spec draft for TV Control API is device internal plugin style 18:35:03 ... maybe they might want to think about websocket approach for the v2 version 18:35:12 [ adjourned ] 18:35:21 rrsagent, make log public 18:35:42 rrsagent, draft minutes 18:35:42 I have made the request to generate http://www.w3.org/2016/02/16-auto-minutes.html kaz 19:31:46 Yingying has joined #auto 20:32:21 Zakim has left #auto