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
Is your feature request related to a problem? Please describe.
Currently customization of the monolithic message module can either be done by "cherry-picking" code from the core and customizing/adding/replacing whatever needs to be customized or "clone-and-own" the entire module. "Cherry-pick" is fragile since it depends on the internal file layout and structure of the message module (implementation), "clone-and-own" is a lot of duplicated code and the possibility of divergence from core development.
It's a similar concept as for a custom OSAL depending on shared or portable elements in the repo, in that cherry-picking is dependent on implementation, not just APIs and the alternative is clone-and-own.
Describe the solution you'd like
Break the message module down into the different parts of the header - CCSDS Primary, CCSDS Extended, CFS Secondary such that they can be included by projects as building blocks, and the "cherry-pick" vs "clone-and-own" is then in the context of smaller modules. Basically if a project wants to customize just the time format, they could either clone-and-own the CFS Secondary implementation or cherry pick. The primary and extended headers could be used as is.
Describe alternatives you've considered
Approach is a project trade, this change makes that decision a smaller impact (less code either way). The code was separated parts of the header by file already as part of #726 to make cherry-picking easier (and secondary is separated by field in the header), but also makes breaking into separate modules easier.
Is your feature request related to a problem? Please describe.
Currently customization of the monolithic message module can either be done by "cherry-picking" code from the core and customizing/adding/replacing whatever needs to be customized or "clone-and-own" the entire module. "Cherry-pick" is fragile since it depends on the internal file layout and structure of the message module (implementation), "clone-and-own" is a lot of duplicated code and the possibility of divergence from core development.
It's a similar concept as for a custom OSAL depending on shared or portable elements in the repo, in that cherry-picking is dependent on implementation, not just APIs and the alternative is clone-and-own.
Describe the solution you'd like
Break the message module down into the different parts of the header - CCSDS Primary, CCSDS Extended, CFS Secondary such that they can be included by projects as building blocks, and the "cherry-pick" vs "clone-and-own" is then in the context of smaller modules. Basically if a project wants to customize just the time format, they could either clone-and-own the CFS Secondary implementation or cherry pick. The primary and extended headers could be used as is.
Describe alternatives you've considered
Approach is a project trade, this change makes that decision a smaller impact (less code either way). The code was separated parts of the header by file already as part of #726 to make cherry-picking easier (and secondary is separated by field in the header), but also makes breaking into separate modules easier.
Additional context
#726, #801
#726 (comment)
Requester Info
Jacob Hageman - NASA/GSFC
The text was updated successfully, but these errors were encountered: