You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To get started with zsomeip, developers must currently cover several tasks that could be hidden or automated:
Writing vsomeip config files and also passing these settings to zsomeip, e.g. by using in-code #define statements. Instead: introduce a common zsomeip configuration file format from which vsomeip and zsomeip configs can be generated.
Defining service/instance/method IDs in vsomeip, both in config files and code. Instead: zsomeip main focus should be on zserio topic/service names, IDs for vsomeip should be autogenerated (maybe with seeds for replicable IDs). Writing these settings manually should be possible, but optional.
Implementing an app with initialization and event processing loop to handle service requests / event publishing. Instead: similarly to zswag, it should be possible to start a service or field* publisher instance by providing a zsomeip configuration file (and service endpoint implementations). Startup and processing loop should be a part of the internal implementation.
The focus should be on easier onboarding for zserio developers who have no prior experience with vsomeip.
* Fields are events with setters - a field publisher is triggered by changes to the field, so no internal publishing logic is needed.
The text was updated successfully, but these errors were encountered:
To get started with zsomeip, developers must currently cover several tasks that could be hidden or automated:
Writing vsomeip config files and also passing these settings to zsomeip, e.g. by using in-code
#define
statements.Instead: introduce a common zsomeip configuration file format from which vsomeip and zsomeip configs can be generated.
Defining service/instance/method IDs in vsomeip, both in config files and code.
Instead: zsomeip main focus should be on zserio topic/service names, IDs for vsomeip should be autogenerated (maybe with seeds for replicable IDs). Writing these settings manually should be possible, but optional.
Implementing an app with initialization and event processing loop to handle service requests / event publishing.
Instead: similarly to zswag, it should be possible to start a service or field* publisher instance by providing a zsomeip configuration file (and service endpoint implementations). Startup and processing loop should be a part of the internal implementation.
The focus should be on easier onboarding for zserio developers who have no prior experience with vsomeip.
* Fields are events with setters - a field publisher is triggered by changes to the field, so no internal publishing logic is needed.
The text was updated successfully, but these errors were encountered: