W3C

- DRAFT -

Automotive WG - Spec Issue Review

14 Jul 2015

See also: IRC log

Attendees

Present
Paul, Adam_Crofts, Dave, Hira, Kaz, Kevron, Qing, Urata, Wonsuk
Regrets
Chair
Paul
Scribe
kaz

Contents


issue 37

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

wonsuk: gives explanation
... Dave raised an issue on api signature pattern
... data point should be a parameter of APIs
... Kevron responded that the original API signature patter was not a bug but a a feature so that we could use JavaScript's introspection capabilities
... Wonsuk agreed with Dave
... Edwin gave some proposal

Dave: there are three proposals

Paul: having datapoint (object) right after "vehicle" or as a parameter?

Dave: plus the third proposal

Kevron(?): contributed native implementation to Genivi
... Genivi is using our implementation

Paul: don't know how to refer to things
... vehicle.get(speed) or vehicle.speed.get()

Wonsuk(?): the last proposal would make the code more complicated

scribe: easier for implementers but harder for developers

Dave(?): when initialize the library, how to initialize the data?

Paul: I need to understand what kind of data is available
... in the backend
... that was one issue
... you could call an API to check availability

Dave: there is a fourth possible option

Wonsuk: we need to ask some of the expert of browser/web application implementers
... which option is useful

Paul: would like feedback from experts
... other groups from W3C as well

Wonsuk: myself also have some questions on subscribe
... similar mechanism like events
... not clear
... event mechanism within browser could be reused

Kevron(?): you don't know the capability
... so we need another mechanism

Wonsuk: in case of Firefox OS, some of additional events can be handled by the browser execution context
... we need to implement "subscribe" for all the possible browser execution context

Kevron: vehicle.speed should be vehiclespeed
... we have engine speed, etc., as well

Dave: who would give comments as implementers

Adam: Paul Wheller

Wonsuk: W3C has the TAG
... how about asking TAG for opinions?

Kevron: would agree

Wonsuk: tried to look for similar specs
... but failed
... in case of Geolocation API
... they also check location information
... that would be similar
... how to design APIs

Paul: originally vehicle.get was used
... looking at existing patterns would be useful

Kevron: this is a new layer of JavaScript APIs
... new features like promises might be related

Dave: retrieval of attributes

Paul: would like to figure out the best way

Kevron: would see the opinion of Paul Wheller and browser vendors

Paul: also we could talk with the TAG

Kevron: vehicle.vehiclespeed.get vs vehicle.speed
... when can I use the function, when it's available?

Paul: how do we want to proceed?

Wonsuk: we can make a page on possible API design options
... and ask the TAG for opinions

Paul: would do that on GitHub or Wiki?

Wonsuk: a new page on GitHub?

Paul: OK
... Dave, Kevron, Adam, is that OK?

@@@: related spec like Geolocation?

Paul: I'll send a summary of this meeting
... actually there are three (=two more) action items
... 2. summary page on GitHub
... 3. contact TAG and Paul Wheller
... how could we contact TAG?

Kaz: we can send a message to the TAG list or we can start private discussion with the TAG Chair, Daniel Appelquist

Paul: pros/cons page on GitHub
... Dave, Kevron and Wonsuk, can you start the page?
... that document would be helpful
... to explain the issue to TAG
... I'll take care of TAG and JLR
... others, please contribute to the pros/cons page
... will send the summary to the group as well.

[ adjourned ]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/07/15 01:21:11 $