W3C home > Mailing lists > Public > public-automotive@w3.org > February 2016

[genivi-w3c] minutes - Genivi-W3C coordination call - 16 Feb. 2016

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 17 Feb 2016 04:07:36 +0900
Message-ID: <CAJ8iq9UuJw33kvBNYz80-AGMivxhbFnm7YF0Ne6idKUVXpXz8w@mail.gmail.com>
To: genivi-w3c@mail.genivi.org, genivi-pmo@mail.genivi.org, public-automotive <public-automotive@w3.org>
available at:

Also as text below.



      [1] http://www.w3.org/

                               - DRAFT -

                        GENIVI-W3C coordination

16 Feb 2016

   See also: [2]IRC log

      [2] http://www.w3.org/2016/02/16-genivi-irc


          Kaz_Ashimura, Philippe_Robin, Philippe_Colliot,
          Klaus_Birken, Gunnar_Andersson, Paul_Boyes

          PhilippeR, Paul



     * [3]Topics
     * [4]Summary of Action Items
     * [5]Summary of Resolutions

   -> [6]https://www.w3.org/2016/02/02-genivi.html Previous

      [6] https://www.w3.org/2016/02/02-genivi.html

   philippeR: agenda: LBS, speech use cases, browser APIs,
   ... anything else, Paul?

   paul: have updated the wiki

   philippeR: last call's minutes

   -> [7]https://www.w3.org/2016/02/02-genivi.html Previous

      [7] https://www.w3.org/2016/02/02-genivi.html

   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:

      [8] 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
   ... 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: [9]https://kripken.github.io/emscripten-site/

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

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

   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 see concrete proposals
   ... GENIVI can't address everything
   ... not only your unit but also other systems
   ... would be interested in having people from W3C

   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 ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [10]scribe.perl version
    1.144 ([11]CVS log)
    $Date: 2016/02/16 19:06:19 $

     [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [11] http://dev.w3.org/cvsweb/2002/scribe/

Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo
Tel: +81 3 3516 2504
Received on Tuesday, 16 February 2016 19:08:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:47 UTC