See also: IRC log
-> 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 ]