Automotive Working Group Teleconference

<scribe> Scribe: Ted

<scribe> scribenick: ted

VISS CfC

VISS CfC

Peter: there was some small suggestions made

Ted: a number of minor editorial, non-substantive suggestions from Sanjeev Ba that I addressed

Peter: do we need a new call for consensus?

Ted: no, they were minor
... we can make minor fixes
... I will prepare the document and work with my colleagues to publish

Peter: any additional agenda suggestions, otherwise we should focus on issues

Ted: after PR we go to Advisory Committee for review and they 28 days to propose changes or object to going to full REC (Recommendation)
... we should have VISS done by the end of the year

Charter

Ted: been working on charter, VISS will only be maintenance mode, VISS v2, RPC and Best Practices
... I will try to have draft of our new charter for next meeting
... still seeking another chair

VISS CfC

issues

issue 348

Peter: issue comes from rather long URLs, Ulf had an idea perhaps influenced by Adnan
... admit occasionally confused on GET v POST

Ted looked up vintage GET v POST article https://www.w3.org/Provider/Style/Input

Ulf: my interpretation of the RFC is requests can contain a message body
... encourage others to read and check my understanding
... I believe it is allowed if not traditionally used
... this will give us more flexibility to handle queries

Ted: Gunnar describes GET v POST use well. payload for POST is name value, full resource content with PUT...

Gunnar: my first understanding is in agreement that POST is used to typically invoke a function on web interface, able to send a payload
... that is a bit different from PUT which is more about publishing content
... POST is about providing data to web server application
... you have path to one signal, in case of GET use querystring...

Ted: we are also deviating somewhat from regular querystring syntax
... there is a limit (2k?) and we can come up with some shorthand

Adnan: it was 1k, now 2 but some libraries still use the lower limit for security considerations

[[GET /multiplePoints?json={"paths":[Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Latitude, Vehicle.Cabin.Infotainment.Navigation.CurrentLocation.Longitude]}]]

Adnan: if you want latitude, just request that part
... both are fine, POST certainly cleaner but this is a good way to structure it

Ulf: so we will have to handle multiple point nodes

Adnan: do we have to?

Ulf: we'll break our pattern otherwise

Adnan: why would you want to request multiple points at once?

Ulf: typically you will want to read a handful of signals and it would be convenient to request them at once, even if in different parts of the tree

Adnan: then you need some modification of the interface specification to allow you to do that?

Ulf: you have to be able to express it

Adnan: linking with special characters is the same as introducing new end points, not a big difference
... if we have to introduce changes in the specification itself, seems wrong

Gunnar: don't think you can have it both ways. either the path is the point on tree or not, can't have multiple paths

Adnan: you can ask for a branch and get eg long/lat at once. if what you want are not in the same branch then you'd be better as a function

Ulf: argument in favor was as a convenience. It is doable with multiple GET requests
... I am fine with that

Adnan: you can do this with WebSocket but not so cleanly HTTP. GraphQL behaves like this and you can combine leaves into a single request and get all the data back

Ulf: agree it is easier to handle in WebSocket

Gunnar: I support Adnan's proposal, single path with branch or wildcards

Peter: I like Adnan's suggestion

MagnusG: benefits of being able to do this outweigh aesthetics and also support Adnan's proposal

Gunnar: we might want to tweak the exact naming, but concept is sound

Ulf: my hesitation is having a magic url, multiplePoints

Ted: you could do this request against top/root node and treat more as a filter

Ulf: yes, or further down depending on what you are looking for. that is a bit cleaner

Ted: if we want to sacrifice readability for brevity, could use uuids

Ulf: good idea but don't like it

Gunnar: you can have multiple operations or different way that using path. filter. Tim and others have pet peeves against known URIs but they're widely used may be an advantage

Adnan posts comment to github issue

https://github.com/w3c/automotive/issues/348#issuecomment-721339681

Ulf: or hybrid, you can provide filter pattern later down in the path

Adnan: isn't this the same as multiple path proposal?

Gunnar: you are focused on a branch, either up at Vehicle level or further down and then treat rest as filter

Ted: again for brevity consideration, maybe only use part of the full dotted node name[s] eg CurrentLocation.Latitude

Gunnar: we should strive to be consistent with WebSocket approach

Ulf: that should be easier to handle

Peter: I was hoping we would come to sampling characteristics one

Issue 346

Peter: we will need more time to focus on these issues

[adjourned]