See also: IRC log
-> https://www.w3.org/2016/02/02-genivi.html Previous minutes
philippeR: agenda: LBS, speech
use cases, browser APIs, security
... anything else, Paul?
paul: have updated the wiki
philippeR: last call's minutes
-> https://www.w3.org/2016/02/02-genivi.html Previous minutes
philippeC: joint call last
December
... API defined in HTML5
... 90% work is done
... API available using Franca IDL
... generated by Franca generator
... common API version 3.1.5
... moved all the enumeration into 32
... checked if it's ok by dated poc
... also into the branch for Franca migration
... the goal is generating the navigation API using Franca
philippeR: some technology for translation?
philippeC: W3C's official
description is WebIDL
... but Ted explained it's not necessary to use WebIDL
... not 100% sure about description for Web
klaus: generate RESTful I/F based on Franca?
philippeC: make sense to start
with Franca IDL during the joint discussion in Seoul
... up to Ted and the W3C guys
... thought the official language for API definition was
WebIDL
... but that is not the case
<philrob> kaz: is it what we are talking about: http://raml.org/
klaus: there was some
transformation mechanism from Franca
... but not sure about the latest status
... we're able to use Franca IDL
... talking about the technical side
... not about who could actually do yet
philippeR: during the last call,
setting up some demo was discussed
... the question is do we have any idea about the
timeline?
... consolidating ideas on Franca-WebIDL transform
... we have already some demo
philippeC: would see to replace the HMI with HTML5
klaus: regarding the option to
generate the code
... the generator is a piece of running reference code
... HTML UI + C++ code
... this work would be usable
... having Franca-WebIDL converter would be useful
... the first step should be architecture decision on which way
to take
paul: no preference myself
kaz: if we want to reuse Franca
resources, would be good to have the converter
... but maybe we could use the RAML mechanism
... or even directly write HTML5 codes
philippeC: tried emscripten
... a tool binding WebIDL
... C++ code and JavaScript
klaus: also JavaScript APIs provided by the HTML5 side?
philippeC: you can use JavaScript codes as well
<philrob> kaz: https://kripken.github.io/emscripten-site/
klaus: communication could be automated
<philrob> correct
paul: we're trying some binding between Franca and WebIDL
kaz: yeah, but usual Web developers just generate JS codes directly
paul: you can support other
bindings
... I myself have not used WebIDL-JS binding, though
... you can get other implementations
kaz: sounds like the model-base
UI approach
... these days people directly JavaScript, though
klaus: HTML UI for embedded
systems
... use built-in C++ codes
... so different situation
... we have to have the bridge between the C++ side and the JS
side
... communication with C++ code on the background
... a set of possible solutions
... we have to choose one
... actually, there was a presentation showed at GENIVI
... using an underlying Node.js server
... something like this could be designed
... hope discussing appropriate level of designing
paul: plugin, websocket
connection, etc.
... the original vehicle API was written as browser
plugin
... talking with underlying mechanism
... client-side API and websocket communication
philippeC: in our showcase two
years ago
... we used JS for the background side as well
... really simple way to implement
... full serialization of data
... communication with the application
... more C++ part on the application side
... FSA demonstrator uses HTML5 UI?
... no. it's QML
klaus: so that is C++
... we have a transformation from Franca to WebIDL
... interested in how WebIDL is usually used
paul: we're getting an action
item
... would provide quick outline
... we have LBS stuff
philippeC: would achieve consensus with the W3C side
paul: agree
... action item for myself
... find the detail on what we have
... solution for tooling
... how to do that
... this is exactly what we do
... either of you, PhilippeC/PhilippeR
philippeC: can provide any help
from the GENIVI side
... on the LBS API
... what is the most suitable technology for the Web
paul: common pattern of
integration
... we have to decide what would be exposed to the Web
runtime
... sort of plugin
ted: just joined
... we should wait for the vehicle API's conclusion
... websocket or WebIDL
... LBS should be consistent with Vehicle API
... currently tendency with websocket
paul: architectural pattern
... we'll come to consensus
... more get involved in the LBS work
... bring the architecture we think
philippeR: we can offer the
GENIVI public wiki
... we can share ideas, diagrams, etc. easily
... something we could provide
paul: don't have strong
preference
... working on the GENIVI side is fine
ted: @@@
paul: we have this collaboration
meeting every 2 weeks
... would see what proposal would make sense
philippeR: W3C's preference is WebIDL?
paul: yes
klaus: not concerning
conversion
... would work for ideas/diagrams
philippeC: everybody can work on the wiki
klaus: would get consensus on the architecture
ted: would like the socket approach
klaus: would have common APIs on
the C++ side
... which communicate with the Web side
... would work for that direction
paul: we have some plan
... philippeC/philippeR, can you send information on GENIVI
LBS?
philippeR: Philippe C is working on that
philippeC: can provide it
paul: we got a call for the
WG
... people are interested in security
... should be a very hot topic
... what would be the best way to talk in Paris?
philippeR: previous security
leader has left...
... need to discuss with Gunnar, the lead architect from
GENIVI
... will have a couple of sessions on security
... but would like to see concrete proposals
... security is a system level concern, not only a head unit concern
... for exchanging on security concerns and on which threats and countermeasures are relevant for the IVI head unit
paul: we come up with an architecture same security model can be applied
philippeR: some kind of working session
paul: good
philippeR: time to split
kaz: these minutes can be public. right?
all: ok
[ adjourned ]