17:17:36 RRSAgent has joined #auto 17:17:36 logging to http://www.w3.org/2016/02/09-auto-irc 17:17:38 RRSAgent, make logs public 17:17:38 Zakim has joined #auto 17:17:40 Zakim, this will be 17:17:40 I don't understand 'this will be', trackbot 17:17:41 Meeting: Automotive Working Group Teleconference 17:17:41 Date: 09 February 2016 17:18:19 Meeting: Issue 72 - API refactoring 17:18:23 Agenda: https://lists.w3.org/Archives/Public/public-automotive/2016Feb/0014.html 17:27:34 urata_access has joined #auto 17:27:42 Present+ Ted 17:28:23 Present+ Kaz 17:28:24 scribenick: ted 17:29:18 Present+ Paul, Peter, Qing, Shinjiro 17:31:41 Present+ Tobie, Kevin, Dave 17:33:10 KevG has joined #auto 17:35:28 -> https://pad.w3ctag.org/p/03-02-2016-minutes.md TAG minutes 2016-02-03 17:36:53 -> https://lists.w3.org/Archives/Public/public-automotive/2016Feb/0014.html Outline for call 17:37:00 -> https://github.com/w3c/automotive/issues/72 Issue 72 17:37:07 -> https://github.com/w3c/automotive/wiki Pros and Cons wiki 17:37:10 I have made the request to generate http://www.w3.org/2016/02/09-auto-minutes.html ted 17:37:38 paul has joined #auto 17:38:26 Paul: Kevron could not attend but sent some notes 17:38:50 … he was an early editor and implemented in crosswalk 17:39:24 … I sent a quick list of high level issues and discussion 17:40:01 … there are multiple issues but the main one being vehicle level abstraction versus sensors 17:40:16 … we quickly get into the mechanisms on how to expose that data 17:40:45 … there has also been interest in web sockets and REST API approach 17:41:14 … I want to make sure we keep this conversation from diverging into tangents 17:41:34 … when this was initially created I shared the QNX guidelines 17:42:02 … the original idea was a vehicle abstraction and removed from underlying infrastructure 17:42:26 … this was conceived for a browser run time in the car (head unit, in-vehicle-infotainment system) 17:42:46 … a number of people from OEMs, Tier 1s and Genivi 17:43:03 -> https://cdn.rawgit.com/w3c/automotive/master/vehicle_data/W3C%20Vehicle%20API%20Creation%20Guidelines%20v4.pdf Vehicle Creation Guidelines 17:43:17 … Genivi if you are not familiar is an open source stack for vehicles 17:44:01 … we chose not to focus on how vehicle data is exposed as that goes down detailed ratholes. It is important for implementers but we needed to focus on app developer 17:44:52 present+ Adam_Crofts 17:44:55 … Webinos was a similar implementation. AutoSAR is a common effort for underlying ECUs 17:45:14 … the way this was conceived is different than traditional web 17:45:43 … there are many sensors in cars and understanding which sensor you are talking to is very important but not for a IVI app developer 17:46:16 … you don't need to know if the speed is coming from transmission controller or what, you just want an accurate value 17:46:43 … there are certainly times you want to know that but not for our intended purposes 17:46:47 AdamC has joined #auto 17:47:13 s/transmission controller/transmission, power train/ 17:47:38 … OEMs do not want random code running in their cars, everything will be heavily vetted, there won't be arbitrary apps installed or car interacting with web in the same way as other devices 17:48:15 … the reason web technologies are being used here is you could potentially take a web runtime app and move across platforms and vendors 17:48:19 q+ to ask about phone-based use case. 17:48:45 … we appreciate all the review and feedback 17:49:35 … basically I would like people working on the current spec to make their case and then get counter point 17:49:58 djensen47 has joined #auto 17:49:58 … we are contemplating a significant overhaul or largely staying the same 17:50:38 … we have a few editors on this call, Adam, Qing, Dave and Kevin 17:50:58 Adam: a key point is going to be CPU usage in answering all the subscriptions 17:51:39 … with a subscription model we can tell the underlying ECU we are done listening. Event based is continuous 17:52:11 … if we go for onchange and have multiple signals within a given interface we need to specify which and threshold we want to know of the change 17:52:21 … those are the two key points for us 17:53:20 Kevin: there are different ways to wrap that model from our current API design or more of a Web socket approach 17:53:44 Adam: we want to take the developer far away from underlying systems 17:54:06 Dave: I don't see those as mutually exclusive or preventing an Event approach 17:54:37 … there is a strong point in trying an approach that will be intuitive to developers 17:55:39 Adam: if you specificy which sensor and zone you want then it would be a new constructor 17:56:06 … handling zones in a subscription model gets complex 17:56:29 Dave: zones are confusing and industry specific, that will throw developers 17:57:02 … I was giving some thoughts with how I would like to redesign the API when Tobie spoke up with Web socket approach 17:57:09 Paul: how does that help with zones? 17:57:52 Dave: if you think of the car as a remote server you can subscribe to a specific piece of data in a given zone and apply certain filters 17:58:01 … you create a callback and you are good to go 17:58:26 Kevin: how do you unsubscribe and let the server know you don't need to keep sending the data? 17:58:49 Dave: I don't believe web sockets have an unsubscribe 17:58:58 Adam: closing apps would close the socket 17:59:47 Paul: concept of life cycle is important, apps will be running in background, some in the foreground and their need for data will vary (polling frequency) 18:00:21 … if it is in the foreground are you getting data every few seconds and pause when it goes to the background? 18:00:28 q+ on lifecycle 18:00:46 Adam: that is why you (as developer) want control over it 18:02:05 Kevin: there needs to be an interface talking to underlying services. We want to expose this API as a JS library 18:02:30 … a best model could call external services 18:02:52 Dave: you want a services based implementation? 18:03:17 Kavin: yes. you can set an event handler to null 18:03:50 Tobie: nothing is telling the underlying service that the last listener has unsubscribed 18:03:59 Kevin: is there a standard way to do this? 18:04:08 Tobie: it is how the web works 18:04:18 Kevin: we have limited processing cycles 18:04:38 Tobie: I understand your desire to have an unsubscribe 18:05:04 … in practice developers tend not to do this so you will need to build in some heuristics to detect when something is no longer being used 18:05:39 Kevin: if you have some careless developers doesn't mean you couldn't have an unsubscribe mechanism 18:05:46 Tobie: agree 18:06:25 Kevin: it seems more difficult and error prone without a server implementation 18:07:10 Tobie: if you want to add a stop listening method you can 18:07:26 … it is something easily built into any system 18:07:37 Kevin: why not have an explicit method call? 18:08:27 Tobie: these methods exist but in practice developers often forget to use them so you will need to detect on your end also 18:09:10 Kevin: how can you tell what the app cares about now and might not later? 18:09:37 Tobie: what I'm hearing is there are things you really care about, like telling the underlying system it doesn't need to continue providing data 18:10:23 … implementors will still need heuristic based garbage collection 18:10:43 Kevin: we already have an unsubscribe mechanism and do not see the advantage in dropping that 18:11:09 Dave: I'm not sure anyone is advocating a single solution, it could be drop listener or unsubscribe 18:12:05 Kevin: if the call is to a web service instead of an interface exposed by the runtime you have to send back to the server the unsubscribe event 18:12:30 Dave: you can add and remove listeners to a pool on the server 18:13:01 … when there are zero listeners you close it and stop procuding the data 18:13:58 s/procuding/producing/ 18:14:10 Kevin: the implementation of the vehicle will effectively be a JS library acting as a proxy 18:14:35 … there needs to be some communication 18:15:25 Tobie: the browser will talk to a server of some kind and through that you want to send an unsubscribe 18:16:29 … I'm working with Intel on generic sensors API and part of the scope of that work was seeing whether that model could apply elsewhere including automotive 18:16:54 … turns out it doesn't apply here but in the process did some review of the spec 18:17:37 … i am coming at this from a different perspective. TAG took a look at the vehicle spec as well last week (conversation resumes tomorrow) 18:18:08 … these two API designs have very different benefits and issues 18:18:15 -> https://pad.w3ctag.org/p/03-02-2016-minutes.md TAG minutes (Feb. 3) 18:19:02 … the extensible web manifesto defines primitives and lets developers develop the types of abstractions they prefer 18:19:18 … if you see common abstractions you may want to gather and standardize them 18:19:53 … this spec is not exposing sensor data but a data bus and you want a JS extraction 18:20:17 … maybe you should focus on the low level data model first 18:21:30 Kevin: you're right, it comes down to what level of API you want to create. something generic and extensible 18:22:02 … implementor might know that an object contains the signals desired and returns that object 18:22:24 Paul: this was conceived as primitives with data, we don't talk about how that data gets there 18:22:32 … it was just about getting at data elements 18:22:53 Tobie: I think you're right but that is not what the spec says 18:23:03 … it is a mix 18:23:20 Dave: it is an attempt as an object oriented approach 18:23:37 Paul: maybe this is the crux of the discussion 18:23:54 Tobie: one of the things coming off the TAG call was the security model, how it is going to work 18:24:12 … what about wanting to use an app from your phone to start the car on a cold day? 18:24:41 Paul: which use cases? 18:24:55 https://www.w3.org/auto/wg/wiki/Use_Cases 18:25:58 Paul: a problem we've consistently had. These were created by Qing An after the spec was created, it is not clear they align 18:26:23 q+ 18:27:20 Tobie: you get all sorts of potential use cases by being able to expose the data 18:27:20 ack to 18:27:20 tobie, you wanted to ask about phone-based use case. and to comment on lifecycle 18:27:37 From the PDF sent last week: "A secondary goal is to allow this API to be used by HTML5/JavaScript applications running on mobile phones to access the resources of a connected vehicle." 18:28:01 Kevin: you need abstraction to make sense of all the data being exposed 18:28:40 Tobie: you can have the same or similar abstraction to an underlying server 18:29:19 s|vehicle."|vehicle." (https://cdn.rawgit.com/w3c/automotive/master/vehicle_data/W3C%20Vehicle%20API%20Creation%20Guidelines%20v4.pdf)| 18:29:25 … the question is what language you are describing your abstraction layer 18:29:34 kaz: yes that one 18:30:42 Paul: the question is where do you place this abstraction - web server listening to sockets or in web runtime 18:30:57 right 18:31:19 … what I think is being suggested is interest in having this as web sockets 18:31:50 … this was started this way because the initial implementation was in crosswalk 18:32:01 … they were already in a browser container 18:32:12 Tobie: this is a frequent debate with no good answer 18:32:44 Paul: it is a matter of picking your poison and the question is what do we see as being the most implementable 18:33:35 Tobie: you need developers being able to pick this up and understand it and feasible for the underlying implementers 18:35:21 Peter: I kind of like Tobie's proposal as a web socket approach, allowing the community to come up with an API 18:35:35 … I see very few subscribe/unsubscribe approaches 18:36:07 … I think this API should be refactored 18:36:18 … problem is that sets us back considerably 18:36:54 q? 18:37:38 Paul: Urata do you want to go through your wiki? 18:37:39 -> https://github.com/w3c/automotive/wiki Pros and Cons wiki 18:37:40 -> https://github.com/w3c/automotive/wiki Urata-san's pros/cons table 18:37:57 s|-> https://github.com/w3c/automotive/wiki Urata-san's pros/cons table|| 18:38:22 Urata: my opinion is that there is one main topic about API style, another on subscribe/unsubscribe 18:38:54 … we discussed with other Japanese engineers and feel there is a preference toward what would be familiar to web developers 18:39:23 … we can go with subscribe style that comes from Geolocation API style 18:39:50 … another thing is the grouping of the data 18:40:17 … if the data is grouped we cannot put a threshold for each attribute we care about 18:40:26 … we understand the reason they want to separate it 18:40:57 … we talked about using the contructor style as well, we are ok either way on that 18:41:12 … we don't find a strong reason for using the constructor approach 18:42:21 … if we go with web socket style approach doesn't that mean anyone can create their own API and no need for this work? 18:42:49 Paul: if I am a developer or OEM and want to expose my data consistently I would want a standard API 18:43:07 Tobie: the Web of Things working group is working on a set of standards that is really close to this model 18:43:37 s/working/interest/ 18:43:55 Here's an idea about using WebSockets: https://gist.github.com/djensen47/293f3b9e4500e778b443 18:43:57 … there are specs defining data models and schemas instead of APIs 18:44:46 Adam: we want to be web appropriate but need to be automotive appropriate 18:45:02 Dave: it is really that different than a factory with 10k iot sensors? 18:45:43 Kevin: take for example in the future when ADAS is more prevelant, you will need to be very careful about which sensors you select 18:46:04 … if you have an abstracted model it is much easier to implement authorization 18:46:49 q+ 18:47:03 AdamC has joined #auto 18:47:27 … if you have 20 things you need to expose for ADAS then you can have one controller that you restrict access to 18:47:42 Tobie: you can do this as a web service layer 18:48:59 Paul: my gut is telling me that we have different leveling, different approaches 18:49:20 … I think the service approach is a great approach but do not see that as ending our current specification 18:49:27 ack k 18:49:36 -> https://lists.w3.org/Archives/Public/public-wot-ig/2016Jan/att-0042/WoT_architecture_20160127_Panasonic-Fujitsu_.pdf wot slides page 3 18:49:50 Kaz: please look at page 3 of these slides 18:50:39 … this is the model of a WoT servient architecture 18:50:48 … it was approved by the IG 18:51:33 … there could be two levels of interfaces 18:52:11 … both versions of APIs could exist 18:52:46 … maybe our level 1 interface follows the current approach and we can try a web socket level 2 approach as well 18:53:25 Tobie: there is quite a bit of approach of going high level API first and then low level and they have generally been disasters 18:53:40 … appcache was an example 18:53:55 … we are having the same discussion in sensors API 18:54:12 … which is why we are ending up at low level primitives 18:54:49 … the chances of building a good high level spec and then the underyling primitives is unlikely, it doesn't happen very often 18:55:24 Kevin: implementers are extremely concerned about safety, less so about getting data compared to setting values 18:56:10 … you also need to worry about resource consumption and if the system stops responding 18:56:59 … having an API that allows developers to be able to quickly create apps is the main benefit 18:57:16 … a low level sensor API makes that difficult 18:57:49 Tobie: That was how I originally saw it but after looking into this space more it doesn't make sense 18:59:07 … I agree with these concerns 18:59:20 … you will need to do this at one layer or another of the stack 18:59:33 … is there a level in the stack it is easier to do that? 18:59:53 … you don't want security at a different level than people are reasoning 19:00:48 … you have a bunch of potential use cases that cannot use this spec 19:02:45 … WoT is thinking about initial hand shaking over http then web socket 19:06:40 Ted @@@ on ECUs that will be handling some of the use cases mentioned not the IVI 19:07:31 QingAn has joined #auto 19:07:43 Kevin: there could be other ECU that will be acting instead of the head unit, other clients receiving signal data 19:09:32 Ted: web sockets approach would likely allow us to be able to handle broader use cases 19:10:37 Tobie: wouldn't cars want to be able to have v2v discussing using the same methods as exposing to head unit? 19:11:23 Paul: the auto industry is looking at web standards primarily for HTML5 and the UI. there are other standards, ISO and other, for different pieces of the puzzle 19:13:06 q+ 19:13:10 q- 19:13:42 Tobie: if there is no long term project beyond what you are describing then maybe the current approach makes sense 19:14:09 Adam: we do have future considerations using web technologies that get into these use cases 19:14:36 Paul: it would be worthwhile to explore the broader possible uses of web technologies 19:14:46 … this group was chartered to get this spec out 19:15:14 … service layer does allow far more 19:15:40 … this conversation is really bigger than the spec in hand 19:16:02 … our original goal was to expose vehicle data to web developers 19:17:06 … i don't feel we have come to any real conclusion on this call 19:17:13 Dave: other than ruling out the sensor API 19:17:51 Kaz: JLR and Access has some prototype implementations already 19:18:34 … using set/get and subscribe can be done using primitives 19:19:12 s/has some/have some/ 19:19:42 Adam: we have not committed to implementing this yet 19:21:13 Urata: practically there is not much difference for implementing 19:21:46 Kaz: if you need some native interaction you could do with JS primitives 19:21:51 Urata: yes 19:22:25 Kaz: our current spec could be the high level API with lower level primitives behind it 19:22:35 Urata: that is one possible way 19:25:57 peterw has joined #auto 19:26:19 Kaz: so theoretically we could regenerate the high-level APIs using the low-level primitives, and hopefully the high-level API set could be the current vehicle API definition 19:28:22 s/definition/definition. In that case, we could expose the high-level APIs for the Web developers to generate Web applications/ 19:29:53 AdamC has joined #auto 19:34:17 Paul: we'll talk with the TAG tomorrow and get their perspective. I hear some interest in a socket approach but not overwhelming agreement 19:34:36 … we should have the higher level discussion on needs of the industry wrt web technologies 19:35:40 AdamC_ has joined #auto 19:36:48 Kaz: one is granularity of API definition and other is transport - sockets or in runtime 19:38:35 s/one is/there (at least) two separate issues. one is/ 19:38:38 I have made the request to generate http://www.w3.org/2016/02/09-auto-minutes.html ted 19:40:22 s/Ted @@@ on ECUs that will be handling some of the use cases mentioned not the IVI/Ted: ECUs will be handling some of the use cases mentioned not the IVI using this API/ 19:40:24 I have made the request to generate http://www.w3.org/2016/02/09-auto-minutes.html ted 19:41:54 s/there/there are/ 19:42:02 Chair: Paul 19:42:06 rrsagent, draft minutes 19:42:06 I have made the request to generate http://www.w3.org/2016/02/09-auto-minutes.html kaz 22:08:12 Zakim has left #auto