<scribe> Scribe: Ted
<scribe> scribenick: ted
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
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
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
Peter: we will need more time to focus on these issues
[adjourned]