<scribe> scribenick: ted
<scribe> Scribe: Ted
Next meeting: 8 January 2019
Ted: based on call attendees we
should largely defer this topic. we also generally covered at the
f2f
... where we are with VISS is appropriate for
now
... technically we need another implementation report but arguably
since there are no requirements for the report could point to
write ups of the other known implementations
... as we are seeing more implementations we should see what we
hear back as it might influence some minor changes before we
finalize VISS v1
PatrickL: Ulf presented very good
first drafts of his two specs
... I looked into the core specification and want to go through
it a bit more
https://raw.githack.com/w3c/automotive/generation_two/spec/Vehicle%20Services%20Interface_Core.html
Ulf: I put this up as an initial
draft and grabbed the first several portions directly from
VISS
... I added a section on data model as well as queries
... security section to add considerations there and then
interface where I start describing our existing methods in a
generic way
... I am trying to avoid transport specific terms
... as mentioned before I drew from M2M as well
PatrickL: RequestId stands out as
something that could get protocol specific
... can you elaborate on its purposes?
[handling of outstanding pull request]
Ulf: only essential information for each method should be there now
PatrickL: timestamp refers to when the data last changed?
Ulf: that too came from VISS but would assume it would be the server response time
PatrickL: in VISS I think it is when data last updated
Ulf: I would like to see it come from the lower layers as well
PatrickL: which could be based on when the system collecting and serving the data via VISS did its polling
Ted: that might be problematic if we are returning a collection of signals, in that case we should clarify most recent
PatrickL: these are details as we go along
Magnus: I seem to remember a timestamp in VSS tree, but unsure what sets it underneath or VISS server
PatrickL: that lines up with
Ted's concern. for some use cases I imagine as something that
might not make sense
... sometimes not necessary
... or placed for certain signals
Ulf: I was trying to draw from VISS but have no strong view
PatrickL: regarding service
discovery, you put it in one of the core methods of the
interface
... response can be the tree that is available/exposed
... another idea would be a description of service and data
available
... I didn't see it as a method but default on an interface
Ulf: except for create and
delete, the other methods were existing ones
... from VISS we had getMetaData but it was not generic enough
and was trying to come up with a better name but service
discovery
PatrickL: that brings up how we
want to construct services
... there will not necessarily be a single service that exposes
all data
... whether there will be a single root for the entire vehicle
or multiple based on different specialties
... if the main purpose is to learn more about the specific
service then that makes sense
Ulf: it could be provided by a single service providing root
Ted: I think we want some form of
service capability inquiry _and_ service discovery on vehicle as
there may be multiple services
... while possible to use eg VISS to handle multiple services from
a top level root, the tree can get massive especially if you
consider media libraries
... we should also give consideration to after-market additions
that could expose signals to the vehicle as a service
PatrickL: I would like to
postpone discovery until a later point
... the Authorize method would be to have the client to send
token to service in order to authenticate itself?
Ulf: correct
PatrickL: un/subscribe would be
to receive notices for specific signals or rather part of
tree
... you would receive proper notification. I question
subscriptionID as perhaps protocol specific as well
Ulf: yes but there is value in trying to keep track of which subscription you are handling in your application
Ted: an application can have multiple subscriptions and want to figure out which is responding
PatrickL: transport would be creating new connections that can be tracked handled differently
Ted: subscription id might be useful for developers who might have multiple concurrent subscriptions for their application and depending on their architecture might find it more useful for keeping track of them
PatrickL: there may be places to
not return ids
... instead of setting subscribeId to -1 I would prefer an
explicit unsubscribe
(from second sentence of section)
Ulf: that came from VISS with some modifications but not attached to it
PatrickL: any other subscription methods come to mind?
Ulf: last time we discussed the
repository Magnus setup and wanted to point out there is a
start in Go
... others are welcome to take approaches in alternate
languages of their choosing as discussed
... there is the start of a client application as well for
testing the server
<magnus> https://github.com/MEAE-GOT/W3C_VehicleSignalInterfaceImpl
Magnus: we are not trying to impose a platform. others welcome, we are following Gunnar's don't choose by committee but by code contributions
Ulf: please try to follow the
architecture description and join in
... at present it is mainly Peter, Magnus and me
PatrickL: glad to see you that far ahead already, it looks great
Magnus: please drop me a line to be setup as a contributor
PatrickL: anything else for this topic?
Ulf: again join in
PatrickL: enjoy the holiday break, see you 8 January
[adjourned]