See also: IRC log
<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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/transmission controller/transmission, power train/ Succeeded: s/procuding/producing/ Succeeded: s|vehicle."|vehicle." (https://cdn.rawgit.com/w3c/automotive/master/vehicle_data/W3C%20Vehicle%20API%20Creation%20Guidelines%20v4.pdf)| Succeeded: s|-> https://github.com/w3c/automotive/wiki Urata-san's pros/cons table|| Succeeded: s/working/interest/ Succeeded: s/has some/have some/ Succeeded: s/definition/definition. In that case, we could expose the high-level APIs for the Web developers to generate Web applications/ Succeeded: s/one is/there (at least) two separate issues. one is/ Succeeded: 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/ Succeeded: s/there/there are/ Found ScribeNick: ted Inferring Scribes: ted WARNING: No "Topic:" lines found. Present: Ted Kaz Paul Peter Qing Shinjiro Tobie Kevin Dave Adam_Crofts Agenda: https://lists.w3.org/Archives/Public/public-automotive/2016Feb/0014.html Found Date: 09 Feb 2016 Guessing minutes URL: http://www.w3.org/2016/02/09-auto-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]