The current code base contains 3 crates (c8y_api, c8y_smartrest and c8y_translator)
containing Cumulocity related code, topic names, message payloads, translation functions ...
The rationale for this structure is not clear. For instance, where is defined the Cumulocity Json format?
Furthermore, many of these Cumulocity related entities are redefined by
the mapper (under the tedge_mapper::c8y module)
and the operation plugins (c8y_log_plugin and c8y_configuration_plugin).
This makes the code difficult to maintain
and things can only be worse over time without a share understanding of
where to add and search Cumulocity related features.
Proposal
The proposal is to have a single crate, named c8y_api to gather all the definitions of Cumulocity specific entities.
This crate will contain both the MQTT api (topic names, message payloads)
and the REST api (uri, content)
as well as the logic (message translations).
The crate c8y_api will not define thin-edge related paths or MQTT topics.
For instance, the directory for operation configurations will be defined into a tedge_api crate.
Same for all the topics used to send operations to the agent.
The code will be refactored progressively.
To start with, we will not define thin-edge related paths in c8y_api.
Candidate crates and modules
tedge_mapper::c8y::converter - remove redefinition of c8y related topics and message payloads
tedge_mapper::c8y::fragments - consider moving this entire module in the c8y_api crate
tedge_mapper::c8y::topic- consider moving this entire module in the c8y_api crate
This refactoring task is part of https://github.com/thin-edge/thin-edge.io/issues/1401.
Motivation
The current code base contains 3 crates (
c8y_api
,c8y_smartrest
andc8y_translator
) containing Cumulocity related code, topic names, message payloads, translation functions ... The rationale for this structure is not clear. For instance, where is defined the Cumulocity Json format? Furthermore, many of these Cumulocity related entities are redefined by the mapper (under thetedge_mapper::c8y
module) and the operation plugins (c8y_log_plugin
andc8y_configuration_plugin
). This makes the code difficult to maintain and things can only be worse over time without a share understanding of where to add and search Cumulocity related features.Proposal
The proposal is to have a single crate, named
c8y_api
to gather all the definitions of Cumulocity specific entities.This crate will contain both the MQTT api (topic names, message payloads) and the REST api (uri, content) as well as the logic (message translations).
c8y_api
will not define thin-edge related paths or MQTT topics. For instance, the directory for operation configurations will be defined into atedge_api
crate. Same for all the topics used to send operations to the agent.The code will be refactored progressively.
c8y_api
.Candidate crates and modules
tedge_mapper::c8y::converter
- remove redefinition of c8y related topics and message payloadstedge_mapper::c8y::fragments
- consider moving this entire module in thec8y_api
cratetedge_mapper::c8y::topic
- consider moving this entire module in thec8y_api
crate