[Magnus shares screen to demo a code generator he is trying to open source]

[seat service YAML, type defs, structs...]

[we can use enums. interfaces with commands but no return values]

[not fire and forget. state reflected in signals]

MagnusF: want to see if people agree on this, what we're putting into the catalog
… can't show code until released. there is a dbus python template, stub code IDL generator
… we have a dump template

Gunnar: you look at ginga (python templating system)?

MagnusF: back in JLR days and forget what we didn't like about it. cheeta works, bit difficult to read

MagnusF: intent is to have enough Franca compatability

Gunnar: YAML syntax a bit different
… if you are formal about parsing, there is potential to have different ways to represent syntax tree

MagnusF: we have a formal syntax though

Gunnar: I guess it depends on how it is parsed and what the python objects look like

MagnusF: it mirrors and expands the tree

Gunnar: there are some Franca/python couplings that might be worth looking at

MagnusF: purpose of all this is to agree on service catalog format, integrate VSS into it
… we have configuration service, deployment file... service file
… I do simple key/value storage for sake of demonstration, would be tied to back end
… I also did a simple http service to be able to GET values
… we then start creating interfaces... interface file picked up from extensions
… even though it doesn't look great, the generated code works

[demo starting config server, client and client profile]

Gunnar: what is a profile here?

MagnusF: user profile, music stations, seat position...
… it allows you to support multiple users (drivers)
… the intersting thing will be in rust, mixing and matching python, rust and later RPC
… you can mix and match between languages and networks
… this is what I intend to open source, will work on rust and a powerpoint to better present
… I understand this may compete with WoT. I see it more as a backdrop for conversation

Ted: I see WoT as a bridge, short and long term as IoT will be desireable after we settle on rpc and it gets established

Gunnar: AGL has a rest interface with JSON, we may want a wrapper for that as well

MagnusF: there may be multiple mappings

Gunnar: big picture for CVII we can make clear the different paths for same purpose. in some cases there will be legacy technology but still benefit from a common underlying model

MagnusF: resulting in different code generators potentially?

Gunnar: yes, but we will see the same VSS/VSC data types, meanings etc

MagnusF: we want model passthrough
… I will look into ginga

YSS and YAML. unattended delivery

Ted will take an initial pass after finishing a grant proposal

MagnusF: I need to think about how to roll VSS into this
… do we want to treat VSS as properties on a global level?
… or we do we treat them as events?

Gunnar: settable and gettable

MagnusF: event for maybe actuation

Gunnar: property if we look at the protocols with get/set and subscription
… an obersvable property

MagnusF: this is going to get interesting. are we going to use RPC to set signals?
… if not...

Gunnar: we discussed what an actuator is. actuator can be written, sensors for only reading
… if you look at the other side, someone/something is writing the value inside the system

Ted: in some cases the events will set/change values and in different order

Gunnars: events are distinct. signals can be confused with events. we may want the named events in VSS tree

MagnusF: then it is an integration question, how to incorporate

Ted: I don't want to go too far in this discussion without Daniel

Gunnar: speculation and discussion fine
… we're not making decisions

Ted: agree

MagnusF: we can extend VSS with an event concept

Gunnar: that is a possiblity

MagnusF: I'll give it more thought