<inserted> scribenick: ted
Magnus gives background history
Magnus: we have shown IoTivity
RVI interactivity and it was well received
... we had a similar demo and meeting at Intel last week
... they are doing the same thing as W3C with VSS but from IoT
perspective
... what we have from Genivi is a commitment to support
OCF
... typically standards are top down, here we are doing the
reverse starting from vehicle perspective and pushing it
upward
... there are many expectations waiting for getting this
information out
... there will be iterations and feedback as this gets more
widespread review
... we want to avoid vendor specific implementations and years
of darwinian standards wars
... we need OCF
... we are coordinating with OMA as well
... they are coming from a telecommunications background
... we are trying to find a fit for them in this OCF, W3C,
Genivi mix
... clearly we need telco at the table
... from their (telco) point of view auto offers them no more
than a way to sell a data pipe and we want more
... for instance we need to know if a door unlock signal gets
delivered
Rudi: nearby Kaz reported yesterday about his meetings with ITU
Magnus: nice
Rudi: they documents from ITU are a bit dense and didn't delve into realtime yesterday but took action to examine further and see whether and how we need to coordinate
Magnus gives an example of not being able to get clear information on bytes being delivered by a major carrier
Kevin: this environment needs to be able to gracefully degrade based on connectivity
Magnus: we need serious traffic
analysis to be able to detect port scanning and anomalous early
for possible probes and attacks
... we'll get there
Kaz: WoT group is also working
with OCF/IoTivity
... another joint meeting between Automotive and WoT at
TPAC
Magnus: we should be sure to have
a presence there
... have you discussed Genivi's security group
rechartering?
Rudi: some and will be talking with them more
Magnus: from RVI perspecitive we are coordinating heavily with this security group
Powell: I see this as a thin
layer on top of web socket, probably going promise based
... don't want to start a religious debate with callback
crowd
<wonsuk> jQuery.get: http://api.jquery.com/jQuery.get/
<wonsuk> jQuery.get: http://api.jquery.com/jQuery.get/
Wonsuk: we can think of our
WebIDL (JS Library) aproach like this jquery model
... since we want to define the api independent of VSS we
should avoid specific attribute set and get function but stay
high level
Powell: I think we can start higher level than that at this point
Wonsuk: I'm just looking for how we can make it as consistent with our web socket approach
Rudi: we are trying to facilitate things for developers
Hira: what are the intellectual properties of jQuery?
Powell: open source, maybe MIT license
Kevin broadcasts a couple examples for JS library
Powell: second vehicle.get
approach and why not abstract the request id to the library as
well
... along with connection, error handling, tokens
... request lifecycle (watch socket for responses to send
back)
<inserted> scribenick: kaz
kaz: thought Urata-san explained he implemented the current vehicle information access api during the april meeting in paris, so we might want to look at his implementation as well
powell: put some sample API definitions on the service spec wiki
junichi: token handling should be
hidden from developers
... also developers' directly specifying long variable name
would be not complicated
powell: put some idea of finding actual long variable name using findPathByCSS method
kaz: theoretically what we expect to this findPathByCSS is the mapping between VSS and the current Vehicle Data as we discussed in Paris
powell: right
... copies the sample codes to his editor and adds some more
edits
kevin: how we document VSS capability?
powell: we could use CSS selector
like JSON query
... (shows some resources online)
adam: goes through the Service
Spec wiki
... WebSocket section
... Message Structure section
<inserted> scribenick: ted
Adam: allow multiple
subscriptions on the same signal
... it can receive message from server with subscription id,
request id and timestamp to verify sucess
Powell: what is the timestamp?
Kevin: time the response was generated
Adam: not linked to any CAN bus timestamp but provided by the service
Powell: why do we need it?
Adam: it might be a leftover from before we had subscription id
Kevin: I'm not attached to it
Shinjiro: older API uses one and
it can be helpful to have
... having a timestamp for the signal is more important, you
want to know how fresh it is
Adam: timestamp should be when
the message is sent
... you may not have it from the underlying ECU only when it is
sent from the service
Shinjiro: different implementations can have more pronounced delays
Adam: not sure how you can consistently get the time from the CAN signal
Kevin: there is no single network
you can get all the signals from, they'll be coming through
different gateways
... you can know it is the most recent at the time it was
relayed
... it is feasible you may be getting a cached value of the
latest received signal
Paul: how long of a processing delay are we talking about?
Kevin: sensor might be sending the information once a second so no point polling every 10ms
Paul: it is useful to know how
long the value should be considered valid
... so what you are proposing is stamping it when you receive
it
Rudi: that is the best you are going to get
Paul: we might want to provide a typical average age of a signal would be - or more a range of how recent/stale it might be
<kaz> scribenick: kaz
adam: goes through "Access Control and Authorization" section
(discussion on "On Change")
(continue discussion after lunch)
[ lunch ]
<inserted> scribenick: ted
[discussion of error codes, concern about introducing custom ones - prefer to find existing applicable]
<paul> http://www.restapitutorial.com/httpstatuscodes.html
Shinjiro: for
subscription_already_active, do we have to prevent multiple
subscriptions to the same tree path?
... it seems we should permit it
Kevin: we could give back the existing subscription id and connection
Ted: but then you risk one client app closing it out from all the other apps
Kevin: true. this idea was to
prevent multiple subscriptions from the same client for the
same information
... we want to avoid multiple logically equivalent
subscriptions
Shinjiro: I may want to use the same information within the same application, in different functions perhaps
Kevin: subscription can be a potentially high cost operation, especially if it is to a sizeable part of the tree
Shinjiro: if I want to use vehicle speed in multiple places within the same application, should I use the same connection or can I subscribe twice?
Ted: similar to db programming you want to avoid overhead (delay) of creating connections, keep it open and reuse for the rest of your interactions
Paul: connection pooling is common too
Ted: 304 not modified seems like the closest although a bit awkward or stretch of the meaning. it is how serve responds to repeated requests (if if-modified-since header is sent which we're not doing here)
Kaz: what if you want different polling intervals?
Kevin: you close connection and create new one
<kaz> draft WG Charter
<inserted> scribenick: kaz
hira: would like to suggest we consider two kinds of VSS definition separately, i.e., (1) Genivi's original VSS definition like WHATWG's HTML5 living standard and (2) W3C's fixed snapshot version like HTML5 Recommendation
ted: we need to talk with Genivi for that purpose
wonsuk: we need more discussion about that
kaz: would suggest we raise
github issues if we would like to add changes to the draft
Charter
... and we'll discuss the issues during our webex calls
... and once we got consensus, we'll update the draft Charter
on GitHub
(all agree)
adam: adds "This spec is
dependent upon the VSS as defined by GENIVI." to the Vehicle
Signal Server Spec part
... also add "Hence, it is conceivable that it is
used/implemented without using the VSS." to the Vehicle Signal
Client Spec part
kaz: Hirabayashi-san still wants
to add some more change about the relationship between Genivi's
VSS and possible W3C vehicle signal definition
... so he should raise an issue on GitHub about that and we
should continue discussion
wonsuk: what is important is "the client spec specifies the API to access vehicle information." or something like that
kaz: let's continue the discussion on GitHub and Telconfs :)
peter: btw, we should check
people's participation in the next f2f during TPAC 2016 in
Lisbon
... maybe we should conduct a survey as usual
<scribe> ACTION: kaz to conduct a wbs survey to gather people's availability for the next f2f meeting during TPAC 2016 [recorded in http://www.w3.org/2016/07/28-auto-minutes.html#action02]
<trackbot> Created ACTION-21 - Conduct a wbs survey to gather people's availability for the next f2f meeting during tpac 2016 [on Kazuyuki Ashimura - due 2016-08-04].
[ Portland f2f meeting adjourned ]