Automotive Working Group Teleconference -- 09 Feb 2016

<scribe> Meeting: Issue 72 - API refactoring

<scribe> scribenick: ted

-> https://pad.w3ctag.org/p/03-02-2016-minutes.md TAG minutes 2016-02-03

-> https://lists.w3.org/Archives/Public/public-automotive/2016Feb/0014.html Outline for call

-> https://github.com/w3c/automotive/issues/72 Issue 72

-> https://github.com/w3c/automotive/wiki Pros and Cons wiki

Paul: Kevron could not attend but sent some notes
... he was an early editor and implemented in crosswalk
... I sent a quick list of high level issues and discussion
... there are multiple issues but the main one being vehicle level abstraction versus sensors
... we quickly get into the mechanisms on how to expose that data
... there has also been interest in web sockets and REST API approach
... I want to make sure we keep this conversation from diverging into tangents
... when this was initially created I shared the QNX guidelines
... the original idea was a vehicle abstraction and removed from underlying infrastructure
... this was conceived for a browser run time in the car (head unit, in-vehicle-infotainment system)
... a number of people from OEMs, Tier 1s and Genivi

<kaz> Vehicle Creation Guidelines

Paul: Genivi if you are not familiar is an open source stack for vehicles
... 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
... Webinos was a similar implementation. AutoSAR is a common effort for underlying ECUs
... the way this was conceived is different than traditional web
... there are many sensors in cars and understanding which sensor you are talking to is very important but not for a IVI app developer
... you don't need to know if the speed is coming from transmission, power train or what, you just want an accurate value
... there are certainly times you want to know that but not for our intended purposes
... 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
... the reason web technologies are being used here is you could potentially take a web runtime app and move across platforms and vendors
... we appreciate all the review and feedback
... basically I would like people working on the current spec to make their case and then get counter point
... we are contemplating a significant overhaul or largely staying the same
... we have a few editors on this call, Adam, Qing, Dave and Kevin

Adam: a key point is going to be CPU usage in answering all the subscriptions
... with a subscription model we can tell the underlying ECU we are done listening. Event based is continuous
... 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
... those are the two key points for us

Kevin: there are different ways to wrap that model from our current API design or more of a Web socket approach

Adam: we want to take the developer far away from underlying systems

Dave: I don't see those as mutually exclusive or preventing an Event approach
... there is a strong point in trying an approach that will be intuitive to developers

Adam: if you specificy which sensor and zone you want then it would be a new constructor
... handling zones in a subscription model gets complex

Dave: zones are confusing and industry specific, that will throw developers
... I was giving some thoughts with how I would like to redesign the API when Tobie spoke up with Web socket approach

Paul: how does that help with zones?

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
... you create a callback and you are good to go

Kevin: how do you unsubscribe and let the server know you don't need to keep sending the data?

Dave: I don't believe web sockets have an unsubscribe

Adam: closing apps would close the socket

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)
... if it is in the foreground are you getting data every few seconds and pause when it goes to the background?

Adam: that is why you (as developer) want control over it

Kevin: there needs to be an interface talking to underlying services. We want to expose this API as a JS library
... a best model could call external services

Dave: you want a services based implementation?

Kavin: yes. you can set an event handler to null

Tobie: nothing is telling the underlying service that the last listener has unsubscribed

Kevin: is there a standard way to do this?

Tobie: it is how the web works

Kevin: we have limited processing cycles

Tobie: I understand your desire to have an unsubscribe
... 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

Kevin: if you have some careless developers doesn't mean you couldn't have an unsubscribe mechanism

Tobie: agree

Kevin: it seems more difficult and error prone without a server implementation

Tobie: if you want to add a stop listening method you can
... it is something easily built into any system

Kevin: why not have an explicit method call?

Tobie: these methods exist but in practice developers often forget to use them so you will need to detect on your end also

Kevin: how can you tell what the app cares about now and might not later?

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
... implementors will still need heuristic based garbage collection

Kevin: we already have an unsubscribe mechanism and do not see the advantage in dropping that

Dave: I'm not sure anyone is advocating a single solution, it could be drop listener or unsubscribe

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

Dave: you can add and remove listeners to a pool on the server
... when there are zero listeners you close it and stop producing the data

Kevin: the implementation of the vehicle will effectively be a JS library acting as a proxy
... there needs to be some communication

Tobie: the browser will talk to a server of some kind and through that you want to send an unsubscribe
... 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
... turns out it doesn't apply here but in the process did some review of the spec
... i am coming at this from a different perspective. TAG took a look at the vehicle spec as well last week (conversation resumes tomorrow)
... these two API designs have very different benefits and issues

<kaz> TAG minutes (Feb. 3)

Tobie: the extensible web manifesto defines primitives and lets developers develop the types of abstractions they prefer
... if you see common abstractions you may want to gather and standardize them
... this spec is not exposing sensor data but a data bus and you want a JS extraction
... maybe you should focus on the low level data model first

Kevin: you're right, it comes down to what level of API you want to create. something generic and extensible
... implementor might know that an object contains the signals desired and returns that object

Paul: this was conceived as primitives with data, we don't talk about how that data gets there
... it was just about getting at data elements

Tobie: I think you're right but that is not what the spec says
... it is a mix

Dave: it is an attempt as an object oriented approach

Paul: maybe this is the crux of the discussion

Tobie: one of the things coming off the TAG call was the security model, how it is going to work
... what about wanting to use an app from your phone to start the car on a cold day?

Paul: which use cases?

<tobie> https://www.w3.org/auto/wg/wiki/Use_Cases

Paul: a problem we've consistently had. These were created by Qing An after the spec was created, it is not clear they align

Tobie: you get all sorts of potential use cases by being able to expose the data

<Zakim> tobie, you wanted to ask about phone-based use case. and to comment on lifecycle

<djensen47> 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." (https://cdn.rawgit.com/w3c/automotive/master/vehicle_data/W3C%20Vehicle%20API%20Creation%20Guidelines%20v4.pdf)

Kevin: you need abstraction to make sense of all the data being exposed

Tobie: you can have the same or similar abstraction to an underlying server
... the question is what language you are describing your abstraction layer

<djensen47> kaz: yes that one

Paul: the question is where do you place this abstraction - web server listening to sockets or in web runtime

<kaz> right

Paul: what I think is being suggested is interest in having this as web sockets
... this was started this way because the initial implementation was in crosswalk
... they were already in a browser container

Tobie: this is a frequent debate with no good answer

Paul: it is a matter of picking your poison and the question is what do we see as being the most implementable

Tobie: you need developers being able to pick this up and understand it and feasible for the underlying implementers

Peter: I kind of like Tobie's proposal as a web socket approach, allowing the community to come up with an API
... I see very few subscribe/unsubscribe approaches
... I think this API should be refactored
... problem is that sets us back considerably

Paul: Urata do you want to go through your wiki?

-> https://github.com/w3c/automotive/wiki Pros and Cons wiki

Urata: my opinion is that there is one main topic about API style, another on subscribe/unsubscribe
... we discussed with other Japanese engineers and feel there is a preference toward what would be familiar to web developers
... we can go with subscribe style that comes from Geolocation API style
... another thing is the grouping of the data
... if the data is grouped we cannot put a threshold for each attribute we care about
... we understand the reason they want to separate it
... we talked about using the contructor style as well, we are ok either way on that
... we don't find a strong reason for using the constructor approach
... if we go with web socket style approach doesn't that mean anyone can create their own API and no need for this work?

Paul: if I am a developer or OEM and want to expose my data consistently I would want a standard API

Tobie: the Web of Things working group is interest on a set of standards that is really close to this model

<djensen47> Here's an idea about using WebSockets: https://gist.github.com/djensen47/293f3b9e4500e778b443

Tobie: there are specs defining data models and schemas instead of APIs

Adam: we want to be web appropriate but need to be automotive appropriate

Dave: it is really that different than a factory with 10k iot sensors?

Kevin: take for example in the future when ADAS is more prevelant, you will need to be very careful about which sensors you select
... if you have an abstracted model it is much easier to implement authorization
... if you have 20 things you need to expose for ADAS then you can have one controller that you restrict access to

Tobie: you can do this as a web service layer

Paul: my gut is telling me that we have different leveling, different approaches
... I think the service approach is a great approach but do not see that as ending our current specification

<kaz> wot slides page 3

Kaz: please look at page 3 of these slides
... this is the model of a WoT servient architecture
... it was approved by the IG
... there could be two levels of interfaces
... both versions of APIs could exist
... maybe our level 1 interface follows the current approach and we can try a web socket level 2 approach as well

Tobie: there is quite a bit of approach of going high level API first and then low level and they have generally been disasters
... appcache was an example
... we are having the same discussion in sensors API
... which is why we are ending up at low level primitives
... the chances of building a good high level spec and then the underyling primitives is unlikely, it doesn't happen very often

Kevin: implementers are extremely concerned about safety, less so about getting data compared to setting values
... you also need to worry about resource consumption and if the system stops responding
... having an API that allows developers to be able to quickly create apps is the main benefit
... a low level sensor API makes that difficult

Tobie: That was how I originally saw it but after looking into this space more it doesn't make sense
... I agree with these concerns
... you will need to do this at one layer or another of the stack
... is there a level in the stack it is easier to do that?
... you don't want security at a different level than people are reasoning
... you have a bunch of potential use cases that cannot use this spec
... WoT is thinking about initial hand shaking over http then web socket

Ted: ECUs will be handling some of the use cases mentioned not the IVI using this API

Kevin: there could be other ECU that will be acting instead of the head unit, other clients receiving signal data

Ted: web sockets approach would likely allow us to be able to handle broader use cases

Tobie: wouldn't cars want to be able to have v2v discussing using the same methods as exposing to head unit?

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

Tobie: if there is no long term project beyond what you are describing then maybe the current approach makes sense

Adam: we do have future considerations using web technologies that get into these use cases

Paul: it would be worthwhile to explore the broader possible uses of web technologies
... this group was chartered to get this spec out
... service layer does allow far more
... this conversation is really bigger than the spec in hand
... our original goal was to expose vehicle data to web developers
... i don't feel we have come to any real conclusion on this call

Dave: other than ruling out the sensor API

Kaz: JLR and Access have some prototype implementations already
... using set/get and subscribe can be done using primitives

Adam: we have not committed to implementing this yet

Urata: practically there is not much difference for implementing

Kaz: if you need some native interaction you could do with JS primitives

Urata: yes

Kaz: our current spec could be the high level API with lower level primitives behind it

Urata: that is one possible way

<kaz> 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. In that case, we could expose the high-level APIs for the Web developers to generate Web applications

Paul: we'll talk with the TAG tomorrow and get their perspective. I hear some interest in a socket approach but not overwhelming agreement
... we should have the higher level discussion on needs of the industry wrt web technologies

Kaz: there are (at least) two separate issues. one is granularity of API definition and other is transport - sockets or in runtime

- DRAFT -

Automotive Working Group Teleconference

09 Feb 2016

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output