<scribe> scribenick: ted
Ulf: I have sent some background mails describing this proposal and patches to VSS
[slide 1]
* Aims at supporting both VISS and VIWI data models.
* Aims at supporting both VISS and VIWI access paradigms.
* Aims at enabling backwards compatibility for legacy VISS clients.
* Aims at enabling “straight forward” porting of VIWI based data.
Ulf: you VISS you address the
leaf node and VIWI the resource node and learn what elements it
has
... you can query to get further information
... I want to support, to some degree and strive for backwards
compatability
... I wish it was possible to do more for VIWI
... VIWI might need to make some concessions and hope that
would be acceptable
... it should be able to straight forward porting
... these are my four aims. Please ask questions at any
point
[slide 2]
* Support for Resource nodes having zero or more element nodes as children.
* Support for dynamically adding/removing element nodes.
* Support for referencing elements of other resources from within an element.
* Support for queries on element properties (not impl in POC).
Ulf: want to support zero or more
child nodes with minimal treatment
... we want to handle adding or removing of element nodes
... they can be added dynamically
... want support of referencing elements from within an element
as done in VIWI
... which is a very useful feature to have
... if we want to also reach aim of supporting VIWI access
paradigm it would need to be added and proven, it was not part
of my patch
... this is what I tried to achieve and what I think is
particularly important to bring over from VIWI
... there may be other parts to bring over as well
[slide 3]
[VIWI resource and element example, image]
Ulf: elements are defined and
named under media collection objects
... definition of the elements seen here in the table. id,
name, uri and items
... any of the four properties are declared or defined by a
name, description, format, unit and values as proposed VSS
solution
... we have different information that describes the properties
of this media collection object
[slide 4]
Ulf: here is my attempt to
codify. I did so under the private.vspec file
... under the branch you see the new node type, rbranch
... in VSS node types are required to have name, type and
description
... we also have child node type
... child belongs to rbranch and can only have element nodes
underneath
... under this proposed VSS elements can only be below child
nodes whereas they could exist anywhere previously
... child properties key name with the value 4 tells how many
properties it has
... then we have six different attributes as you can see in the
table
... in my first email I didn't produce a list. this can perhaps
be improved for readability
[media object example on slide 4]
Ulf: rbranch works better for
element to element linking
... I also took from the media items part from VIWI submission
for one element
... you can see this in this new VSS syntax
... data here is taken from VIWI. the items part I implemented
as a yaml list
... in python it is represented as a list
... in VIWI all nodes need to have id and uri. id needs to be
unique
... this media items information points to the resource and the
children under it
... that is how I tried to go from the VIWI model to VSS and be
able to hopefully have the same information and
functionality
[slide 5]
Ulf: Rudi asked me to update the
README file so I produced the accompanying tree image
... the signal tree is found under the vehicle service
... you'll recognize the VSS tree structure with rbranch and
under that zero or more children
... questions or comments?
PatrickL: I like very much how
you integrated these basic concepts of how subelements of a
resource can fit into a VSS tree model
... it makes sense
... references as one of the main features
Rudi: I have been working with Ulf a bit in the background and from VSS point of view I see it as a valuable extension to the model and would welcome the merge request based on this patch
Laurent: is the VSS tree static?
Ulf: good question...
Rudi: it started out as a static
definition but it has the ability to be extended, even
dynamically
... for media it should be extendable for sure
Laurent: VIWI is a distributed service. if I have a VSS server would it be possible to register itself and be exposed within the tree?
Ulf: there are no mechanics that should prevent that from happening
Rudi: from a technical point of
view it is absolutely possible
... it should be possible to proxy a query onto VIWI
Laurent: if I ask for a car do I
get every signal in the car?
... in some cases, eg media, I would want to switch to VIWI
knowing that the particular node is VIWI backed and query
it
... maybe all I need to know is a media service is there
PatrickL: as a developer you
would want only one style of communicating with the
vehicle
... whether the source comes from something else should be
transparent
... I should stick with the original way of communicating
... the distribution is not something I have a clear idea about
at this point
... for Laurent and I it is important to have that query
capability
... how the representation is being built is something we can
talk about
... the VIWI style in the VSS tree is great
Laurent: I am trying to think
about dynamic mounting and query capabilities
... maybe a client could still talk to media node directly VSS
style
... it can exist in a tree with one trunk. individual services
would be trunks and in a central VSS exposed through a
registry
PatrickL: then the question would be how to create a reference across services
Benjamin: if you keep going with
the id that VSS is carrying you can turn the branches into an
equivalent
... code can convert VSS vspec to resource collection
... one of these extensions could be adapted to present the
VIWI model since they come from the same source
... if I take the tree in front of me, there could be an
element fuel type. it is well defined in both models
... they can have the same semantics and meaning since they are
being produced from the same vspec file
... I will look at the script you created in more detail
PatrickL: this works well to get
structure. to distribute implementations is not clear with such
a tree
... if we have distribution how we would produces addresses
across the different trees is still unclear
... regarding what queries shall be possible we can look at the
previous discussion and what VSS provides and maybe extend it
too
... my question for VSS tree: what is the difference between
attribute and signal?
Rudi: attributes are things that don't change, like "length of car".
PatrickL: why do they need to be different types?
Gunnar: the client, knowing that an attribute is constant, only needs to ask for it once, as opposed to signals.
PatrickL: I would like a leaf in a tree to identify whether it is likely to change (or static)
Benjamin: it would depend on the implementation than the model
PatrickL: anyone have thoughts on
next steps?
... this is definitely worth further investigation and we
should find solutions for the questions raised
... let's further by email