Protobuf use static uid

[eriksven]

This PR extends the protobuf generator to use the static-uid which would be created in a previous step with vspec2id generator. The PR also adds the feature to make all fields in the generated protobuf file to optional.

Using the static-uids has some drawbacks but the previously existing approach of using incremental field identifiers has some issue regarding backwards compatibility. Because of that I want to propose the alternative solution of using the static-uids. More details on the advantages and drawbacks of both approaches are available in the new vspec2proto.md Documentation.

[erikbosch]

MoM:

• Please Review

[erikbosch]

Do you also get warnings like:

WARNING Attribute(s) staticUID in element Major not a core or known extended attribute.

In https://github.com/COVESA/vss-tools/blob/master/docs/vspec2id.md#generate-eg-yaml-file-with-static-uids they include -e staticUID in examples to avoid warnings

I am thinking if we promote staticUID to a core_attributes so that you never get a warning. Thoughts @adobekan

[eriksven]

Yes, I do get these warnings too. I thought this would be "normal" since staticUID is not a core_attributes. So thanks for the hint of how to avoid the warnings. I will have a look into it.

[erikbosch]

Short term I think you could just add -e staticUID in the example. But I am thinking of the long term solution where I see multiple alternatives:

• Promote staticUID as an allowed/core attribute for all tools always
• Add it in some way as core-attribute for the specific tool, regardless of whether --static-uid is used or not
• Add it only if --static-uid is used

For the last two alternatives we should find a common mechanism that can reused by all tools. I anyway not see it as a topic for this PR.

[eriksven]

The documentation now contains an example with the parameter -e staticUID.

[adobekan]

@eriksven
I'm not sure if directly comparing static IDs with field numbers at the end makes sense. If we're using static IDs, the message description would likely be different. Additionally, I'm uncertain if we should describe any aspect of VSS in that area.

[erikbosch]

MoM:

• Please review, possible merge decision next week

[erikbosch]

@adobekan @eriksven - do you intend to participate in the meeting tomorrow (Tuesday 7th)? I think it would be good to agree on if we see any problems with this PR. My view is that this an option that does not affect default behavior, so if someone thinks this is a useful addition it is ok for me

[eriksven]

@adobekan @eriksven - do you intend to participate in the meeting tomorrow (Tuesday 7th)? I think it would be good to agree on if we see any problems with this PR. My view is that this an option that does not affect default behavior, so if someone thinks this is a useful addition it is ok for me

Unfortunately, I am not able to join the meeting today. But I could join one of the next meetings.

[erikbosch]

MoM:

• Adnan - If I would use static id I would not this approach, it would be more useful if one would use generic message. Would be good to have SvenErik available for a discussion.
• Erik: Could be useful if server use 4.2, client 4.1
• Adnan: But then we could use a thin API (id+value), no need for fat API, but both approach valid, but we need to document both options.
• Erik: Possibly discuss next week
• Gunnar: Could it help if @eriksven describe intention with change better
• Erik: discuss next week if this one needs to be part of 4.2

[erikbosch]

MoM:

• SvenErik presented a bit on the background, using staticuid gives an opportunity to generate messages
• Erik: Do not really see any blockers, it is optional, could be useful in some scenarios
• Merge