Ted summarizes emails and calls on latest convergence attempts

PatrickL: are we in good shape for next week's meetings?

Ted: small f2f crowd but not critical mass for our main topic. ws & meetup going well

PatrickL: I think we should have sbranch further in the mail thread

https://lists.w3.org/Archives/Public/public-automotive/2019Aug/0029.html

Ted prompts Ulf to introduce rbranch

Ulf: I originally thought of this for being able to bring ViWi data to VSS not the other way around
... it is possible to help migrate data from a ViWi model such as media to VSS
... without rbranch it is hard to identify what a child looks like or if there is even a child
... a resource in ViWi doesn't need a child node but it is possible and you can find out the metadata to see if there may be children, rbranch introduces that
... in theory it should work and did some simple test translations but haven't tried a full tree

Ted: anyone besides Laurent have thoughts on sbranch?

PatrickL: besides the email unsure about the details of the proposal

Ulf: I am not sure how sbranch would help with migration in the other direction

Ted: @@3level

PatrickL: every level within ViWi expresses a certain type, service, resources and bundled data set (nodes)
... they are not really comparible given the fixed meaning and structure

Daniel: does every microservice have its own endpoint in discovery or everything from one connection?

<PatrickLue> /<service>/

<PatrickLue> /<service>/<ressource>/

PatrickL: the lowest level root would be service, next resource and third element[s]. it isn't about a tree really

<PatrickLue> /<s>/<r>/<element>/

PatrickL: there can be multiple services on the same level. elements have several properties

Daniel: for me, microservices are a thing of infrastructure. in VSS you could have subtrees served by different service implementations

PatrickL: there are multiple things mixed in the idea. for microservice we expect well defined apis and only allowing the service to interact through it
... there could be multiple microservices, for instance say anything below .../seat is handled by another service instance
... the service resource element could be described further and will do so by email

Gunnar: consider what the HTTP request looks like, we should focus on that and figure out the piece behind it
... a few goals: VSS tree has been expressed as a good structure and there is a desire to have REST requests reflect that structure
... the three depth limit could just be another way to serve those resources
... we can leave aside eg uuid for now

[tangent on uuids and alternate uri paths]

Daniel: there were merits for requesting unique ids for resources
... point of Gen2 is to be developer friendly
... main focus should be the path

Ted: @@alt_data_structures

PatrickL: so far people have understood to make their service available there is a structure they need to follow
... there have been times where they have had flatter views and challenge to get to depth

Ulf: about ability to address unknown data models, the chance of being able to do that is greater with VSS model vs ViWi since former is more flexible

Daniel: you have graph interface there, how do you know if you are querying the third level?

PatrickL: for tracks you would request everything on the third level

Daniel: how do get down to track level in media example, that seems deeper?

PatrickL: yes that is the forth level I alluded to

Daniel: media player/media collection/album and then how deep can the property level go?

PatrickL: it is possible to have tree below that but can only filter on properties
... URL always starts same
... if not given any filter arguments gives you full json element

Daniel: service discovery for first url you don't have since it stays the same?

PatrickL: every service is responsible for adding itself to registry, could be solved with something like mdns
... everything is known and discoverable. all services bring themselves to the service registry

Daniel: that could be different services from VSS branches registering themselves

PatrickL: correct

Daniel: you could just serve VSS there

Benjamin: why can't you have resource and subresource?
... I don't understand this depth limitation as it doesn't align with REST principles

Daniel: REST doesn't have such limitations
... service can be defined by the host contacted and could use different microservices transparently beneath it
... an option for Gen2 would be to simply remove the depth limitation

PatrickL: we want to avoid adding complexity
... easier for someone interested in a certain topic to filter at a higher level than drilling deeper

<PatrickLue> Media Service Description https://www.w3.org/Submission/2016/SUBM-viwi-service-media-20161213/

Daniel: if a query is easier, we need to do a true comparison

Tuesday morning PST during f2f will continue this conversation

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: John Ted Adnan Glenn Benjamin Ulf Joakim Gunnar Sebastian PatrickL Daniel
No ScribeNick specified.  Guessing ScribeNick: ted
Inferring Scribes: ted

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 03 Sep 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)