-> 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 ]