Volvo assessment of Signal / Resource access
Ulf: my colleagues Peter and
Joakim together with Magnus (Melco) looked at the different
transports of VISS and ViWi (RSI), sockets and http
respectively
... ideal if we want to support both protocols would be if the
payload could be transport agnostic
... we want to analyze the feasibility
... on screen you can see to the left examples of different
actions, subscribe, get etc
... payload response is in JSON
... what we found in ViWi is on the right in a chart with
different levels of URI resolution
... we wanted to see if this could all be mapped. i categorized
three different areas
... this is our analysis and might be flawed, please point out
any issues you might see
... area 1 maps to get and set actions of VISS
... area 2 maps to getMetaData action
... area 3 concerns adding and removing nodes in tree which is
something VISS is not capable of
... from this we tried to draw some conclusions
... we do not believe it is possible to have identical payloads
sent over these protocols
... VISS get and set maps to HTTP GET and PUT (or POST)
... HTTP URI path itself contains information that would be
better as part of the payload
... area 3 outlines things capable in ViWi that VISS cannot
handle at present, it can be added but would be a rather
substantial change
... possible but adds complexity
... we can decide to have part of both or limit these actions
to HTTP only
... same information can be sent but in different
payloads
... we came up with an alternative idea, using profiles. one
geared more for signals other resource
... we thought area 3 only belongs in resource access, so
HTTP
... for subscription we think both should use web sockets
... get and set should be in both
... metadata in ViWi is over HTTP and VISS, sockets
... we think sockets were more suitable
... the security part with token and OAuth2 is the same in both
and should be
... this could affect other functionality like advanced
query
... what is described in ViWi is needed, VISS would benefit
from it as well
... signal access profile would be less complex and easier to
implement
Magnus: we had some discussions about risks of having profiles, whether the specification can diverge that way
Ulf: profiles would allow for different functionality for the access methods
Gunnar: a few initial
thoughts
... regarding same format for the payload, JSON is hierarchical
and could be sequential - list of several things
... an addressing part and data part. the data format could be
the same
Ulf: I agree
... it would still not bring us to identical
Gunnar: closer though
... I have a fair idea between POST and PUT but in your
assessment you have either as being able to create a new
node
... maybe there is more reason there
PatrickB: PUT would do if you knew resource location otherwise you would be POST and a uuid would be generated
Gunnar: that matches my
understanding
... regarding formats and different features, when I pointed
out WAMP it wasn't adopted nor advanced as a topic
... there are a number of features we would benefit from and
worth another consideration
... it came up in IETF and later OASIS contexts
... they do have a HTTP bridge that isn't formally specified
but implemented, it handles socket and HTTP
... we should go through some scenarios in more detail to see
if they even make sense for signals
<Zakim> ted, you wanted to ask about VSS pull request
Ted: earlier you cited how in HTTP the response body itself does not contain path, it is handled in headers. your pending VSS pull request had similar ambition, to not rely on VSS tree path used to access the information but have it in the payload. we should do the same here
Ulf: in sockets it is done with
path key/value and could use dot notation
... it can have same semantic meaning to server
... HTTP manager could extract path part of URI and include in
resource body in class notation
PatrickL: to clarify the profiles would map the transport protocol behavior onto the transport used
Ulf: correct
PatrickL: the payload should
match the idea of the methods as well. the payload with the
headers should be part of the profile mapping as well
... the mapping of the methods and return values are
descriptions in the profile. this gets complicated on POST,
sending JSON
... every suitable transport protocol must match their return
values. it doesn't make a difference to describe how the verbs
and return has to be understood
... thinking about MQTT about another protocol complicates
things, what is important is that the same information is
returned
Laurent: we should not mix
headers and content, replication in headers is a particular of
the protocol. my design should not be limited by the protocol
itself
... think of the developer and avoid have them mix and match
accessing information from a HTTP request
... in BT world you have different profiles about
functionality
... in mp4 you also have profiles which define what operations
you can use to decode the format but that is very
different
... is the profile for the content or the operations?
... it makes sense to have a signal profile and another which
might provide more content
... I would use profiling to help the developer to select the
appropriate access method
... what are the technical challenges that this profile
solves?
... if we forget about the two access methods and take a step
back and look at profiles, they are to help with different use
cases
... we should have as consistent a payload as possible
regardless
Ulf: I see our idea here as
profiles at handling methods and content the same
... content and format should be the same
<Zakim> ted, you wanted to mention JSON-LD
Ted: when PatrickL was discussing POST not being able to send JSON like VISS set, I am reminded of JSON-LD which is meant to send data back with any modifications back to the server as JSON. something to consider especially since that is how Web Of Things group is going
PatrickL: I need to reflect
further but see this as going in the right direction
... any more questions?
... next week we will return to this topic as a recap and get
into covergence todos lists
[adjourned]