https://www.w3.org/auto/wg/wiki/VISS-RSI-convergence-framework#TO_DO
PatrickL recaps previous meeting
PatrickL: URI seems the obvious scheme to use and want to start with that here, see if there is agreement
Ulf and Ted concur
PatrickL: good, let me push the
envelope and see if you won't agree...
... the protocol scheme we would like to use would be like
viss
Ted: so we would be defining our own protocol?
PatrickL: did we settle on http[s]?
Ted: i could see protocol-less before creating a custom protocol but that would be difficult for implementers
Ulf: why are we discarding http?
Laurent: how (the protocol) we
access the service is not important
... how matters less than what comes next
PatrickL: the where (hostname)
comes next. your client needs to know where to find what you
are accessing
... IP addresses and DNS name resolution is fine here. it is
not that important to know the where if there is a service
registry
... that brings me to the path part of the URI and it describes
what we want to have
... it would be ideal if the path describes explicitly what we
are accessing
... how, where and what in the URI and we should focus mostly
on the latter, it is what the developers are most interested
in
... does that make sense to all?
Ted: it does to me
PatrickL: next part is the
querystring, what comes at the end of URI after ?
... addressing scheme then becomes how, where, what and then
more selective and consistent with the http world
Ulf: sounds OK to me
Laurent: what is the fourth part?
PatrickL: querystring, acts as a filter or search
Tim: I am trying to visualize how the path would be used differently than the querystring
PatrickL: path would describe what the developer is looking for, in media example list of artists, and then a filter for specific artists
Tim: a modifier
... ok, sounds sensible
PatrickL: not a new idea, making sure we are on same page when it comes to addressing
Tim: will we use HTTP verbs as well?
PatrickL: they are generally well
known and observed, well some don't know PUT etc...
... it would make sense to use verbs from HTTP
Tim: in VISS web sockets, action is in the body. while that is a way to go, I would prefer to use an existing protocol
Ulf: I think the complete specification should support more than one protocol, HTTP and Web Sockets
PatrickL: there it would make
sense to use multiple protocol schemes, they can access based
on developer preferences/needs
... ideal would be consistent verbs and support MQTT, WS, HTTP,
etc
Tim: it feels that might get
sticky with the nuances of the different protocols
... MQTT does not have the same notion of verbs
... a least common denominator would be preferred for
consistency
... not sure how we can make that work though
PatrickL: my intention was to
make it possible to adapt the way we describe data to multiple
protocols and keep consistent with a RESTful manner
... try to stick with as much as possible with HTTP for the
others
Ulf: I agree with the statements expressed
Laurent: it is nice to reduce the load on the developer
<PatrickLue> <how>://<where>/<what>?<filter_and_so_on>
Laurent: MQTT is not that far
off, in the end we are transfering a payload
... agreeing on payload itself is important. their verbs are
close and not really shoehorning one into another
... as Ulf said in his email you can figure out what to do
where (in viwi vs viss)
... we have to recognize signals are different than other
"resources"
... we can agree on the broad strokes and need for
subscriptions
Tim: sounds good to me
PatrickL: we are going rather quickly and see we are in agreement
Ulf: I am hesistant in using CAN
bus style that you mentioned, in my opinion that should be
abstracted and that is too internal
... that would lead us to debating LIN and Flexray
PatrickL: I agree, that was the old automotive guy in me using it as an example
PatrickL: looking at todos list for next topic, service registry perhaps
PatrickL: I am bitten by the
microservice bug, I am starting to see them everywhere and use
to solve everything
... they can be built quite well by a department within a
vehicle realm and tied together
... everyone is responsible for their microservice and in order
to bring them together, need a registry to find them
... that way I do not need custom configuration for a
vehicle
... for me that is a registry. a developer would be able to go
through a registry to see all that whats that are
available
... that way if I am looking for a specific thing, I can take a
look in registry for it and learn which service provides in
with which protocols and address
Benjamin: I know nothing about microservices, can you explain what you can combine, how it works?
PatrickL: you build a function
and provide an API to it through a service
... you access it through TCP/IP over the network. think of it
like classes scaled to a network level
... instead of compiling all those classes together to use
functionality it is more a living world
... services can use others
Benjamin: sounds auto specific
Ted: you can think of these microservices on vehicle like a microcosm for the web - registry is search engine, media is your content, etc and developers are coding interactions with them
Joakim: do you see different parts of the specification implemented by different services?
PatrickL: I would like to go to our media department and tell them how I want to access their offering through a service and they would provide it
Joakim: modifier (querystring) doesn't really apply well to signals, once you are subscribing there is no need to filter
PatrickL: a developer might be interested in accessing information only about the driver's seat and not all seats
Joakim: in some cars you can
change the configuration
... eg different number of seats
PatrickL: yes but I should have a
static representation of all seats and could either handle it
within my (developer perspective) code or offload to server
with its filter capability
... we want to be able to handle both, correct?
Magnus: wouldn't having a service registry break the idea from VISS of having different branches offered by different services
Laurent: just because we have
filtering, you don't have to use it
... the registry helps you find stuff. now if you decide to
implement an endpoint under a single service host, that is your
decision
... registry could be next to or even same server as VISS
PatrickL: it breaks the mental
model of VISS, it is not necessarily a one stop service
... from an implementation standpoint, the VISS model would
need to proxy all information from potentially different
sources
Ted: we have the same issue in VISS. earlier we envisioned the possibility (due to implementer choice, different trim levels for a make and model or aftermarket integration) of multiple VISS servers in the vehicle. I believe the spec reflects that but doesn't describe how nor how to handle broken branches. we don't have a solution yet
Tim: I am reminded of a service I
use where the core server provides URIs for other
services
... that registry service, if request recognizes it, provides
notional server id[s] for microservice[s] that provide desired
functionality
PatrickL: that makes sense to me
Ulf: if we have a tree in the
specification, I don't really like separating the registry from
the tree
... having separate logical parts found at different locations
is a dangerous path
... they may contain similar information and you want to avoid
exposing something multiple times
... we should strive after one structure containing all we are
talking about, if we have a tree at all
Tim: I agree but what it sounds
like to me is the registry is the root of the tree
... it can tell you the branches it presents
PatrickL: I can have engine and
trailer service implementations in two places. I can either try
to address both services independently or have a registry
expose both
... regarding having things defined at multiple locations, I
agree that is not desireable
Joakim: if the tree is both the API and the modal, couldn't the registry return the nodes available on a given car?
PatrickL: definitely
... one of the arguments for the tree in the VSS is that it is
searchable based on partial path and *
Joakim: you can either access the tree or ask what nodes are available
PatrickL: it works that way but requires multiple connections
Joakim: another concern is adding complexity when we should be working to make it easier for devlopers
PatrickL: it would be easier if
all the information was available in a central location
... am I correct in hearing pushback from the group on concept
of registry?
Ted: I see it more as hesitation and if the group understands how you are doing your registry more they can get their heads around it
PatrickL: I can do that next week
Ulf: in a simpler model you would not need a registry unless you are adding or subtracting nodes
[adjourned]