docs: add design for abstraction layer API to be used by user code#46
Conversation
|
|
||
| package "Design Goals" as DesignGoals {} | ||
|
|
||
| package "API Layer between user code and concrete SOVD client implementation" as DesignGoals.Goal01 {} |
There was a problem hiding this comment.
should it be "and concrete SOVD server implementation"?
There was a problem hiding this comment.
No, since this API layer is intended to be located on top of a specific client implementation (binding) which performs the actual communication with the SOVD server.
There was a problem hiding this comment.
@stmuench so this is not the API layer between SOVD server and Service APP (-> high level architecture)? But this API layer is on Client side?
I´m a bit confused, because this PR was introduced as "This is a proposal on the API between Applications and SOVD Server". Or maybe with "Applications" it was meant applications on SOVD client side...
Please create a reference from this design to the "OpenSOVD High Level Architecture"
| package "hence, user code must provide certain pieces of information as depicted by this design upon registration of SOVD Operations and/or Data Resources" as DesignGoals.Goal02.Note01 {} | ||
|
|
||
| package "user code shall have minimal hassle w.r.t. to creating as well as having to populate native SOVD reply payloads" as DesignGoals.Goal03 {} | ||
| package "ideally, the API layer shall create native SOVD data structures and populate these from the user code's data structures, e.g. to JSON" as DesignGoals.Goal03.Note01 {} |
There was a problem hiding this comment.
do we expect, that data conversion also to be considered in the API layer?
There was a problem hiding this comment.
Ideally, yes. Feasibility is nonetheless subject to be demonstrated.
| +With<UDSServiceType>(Identifier, Args&&...) : DiagnosticServicesCollectionBuilder& | ||
|
|
||
| .. native SOVD APIs .. | ||
| +With<ReadOnlyDataResourceType>(Identifier, JsonSchemaView, DataCategoryIdentifier, optional<DataGroupIdentifier>, Args&&...) : DiagnosticServicesCollectionBuilder& |
There was a problem hiding this comment.
Is the DataCategoryIdentifier an output from the user in this design?
I guess it should be more a configuration item, as the DataCategory is a mandatory attribute in the SOVD response and will be not provided by the legacy UDS API
There was a problem hiding this comment.
I guess for legacy functionality, we would simply provide some predefined category identifier implicitly
There was a problem hiding this comment.
When querying data items from an SOVD Server, users should also see the UDS ones and not only native SOVD-exposed ones. Hence, we need to find a way to merged them, if we want that.
On the other hand, exposing legacy UDS functionality under a custom predefined category would have significantly less implementation efforts and is anyways only expected for a rather short transition period. Ultimately, all apps are subject to get migrated the native SOVD APIs.
| } | ||
|
|
||
| interface Operation { | ||
| API definition for SOVD operations |
There was a problem hiding this comment.
Is this user interface for user code on HPC? On an HPC we have typically no I/O Control
There was a problem hiding this comment.
I/O Control seems to be only relevant for ECUs which have dedicated I/O ports. And HPCs typically do not have such.
stmuench
force-pushed
the
middleware_api_layer_design_for_user_applications
branch
from
71b5bd7 to
2c9baca
Compare
stmuench
force-pushed
the
middleware_api_layer_design_for_user_applications
branch
from
2c9baca to
15e2633
Compare
stmuench
changed the title
stmuench
force-pushed
the
middleware_api_layer_design_for_user_applications
branch
from
15e2633 to
e34629d
Compare
lh-sag
left a comment
lh-sag
left a comment
There was a problem hiding this comment.
Maybe this API should move to SCORE instead of opensovd.
stmuench
force-pushed
the
middleware_api_layer_design_for_user_applications
branch
from
e34629d to
ce5e869
Compare
stmuench
force-pushed
the
middleware_api_layer_design_for_user_applications
branch
2 times, most recently
from
93a905d to
63dee81
Compare
docs/design/cpp_abstraction_layer_api_for_user_applications.puml
Outdated
Show resolved
Hide resolved
docs/design/cpp_abstraction_layer_api_for_user_applications.puml
Outdated
Show resolved
Hide resolved
docs/design/cpp_abstraction_layer_api_for_user_applications.puml
Outdated
Show resolved
Hide resolved
@lh-sag but then we would not have any API layer in opensovd. We thought that S-CORE should simply consume this one as-is and we maintain the API's stability here in opensovd. Or would you have a different opinion here? |
stmuench
force-pushed
the
middleware_api_layer_design_for_user_applications
branch
2 times, most recently
from
dd6649f to
c147ff0
Compare
stmuench
force-pushed
the
middleware_api_layer_design_for_user_applications
branch
from
c147ff0 to
32d3c2b
Compare
8 participants
Summary
Checklist
Related
Notes for Reviewers