[Moims-sc] M&C Book revision

Coelho, César cesar.coelho at cgi.com
Thu Dec 14 13:41:33 UTC 2023


Trusted 3rd Party

Hi Serge,

I agree with your assessment, option 1 seems to be the best.

Best regards,
César Coelho


From: MOIMS-SC <moims-sc-bounces at mailman.ccsds.org> On Behalf Of Serge Lacourte via MOIMS-SC
Sent: Friday, December 8, 2023 5:13 PM
To: moims-sc at mailman.ccsds.org
Subject: [Moims-sc] M&C Book revision

EXTERNAL SENDER: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
EXPÉDITEUR EXTERNE: Ne cliquez sur aucun lien et n'ouvrez aucune pièce jointe à moins qu'ils ne proviennent d'un expéditeur fiable, ou que vous ayez l'assurance que le contenu provient d'une source sûre.



Dear all,

I am about to release the new version of the M&C Book to the working group. However I would like to get first your opinion about an API change, which impacts several operations.

With the move from COM objects to MAL v2 objects, I initially changed the API of several operations to accept a List<ObjectRef> parameter (instead of COM objects identifiers). Then we agreed in WG to change this API into a single domain and a list of keys, for a subset of those operations, namely:

  *   Parameter: getReportingConfiguration, enableReporting, disableReporting, setReportingPeriod
  *   Alert: getAlertConfiguration, enableGeneration, disableGeneration
  *   Aggregation: getReportingConfiguration, enableReporting, disableReporting, setReportingPeriod

It looks now inconsistent with a few other operations, which still use a List<ObjectRef> parameter, namely

  *   Parameter: getValue, setValue
  *   Aggregation: getValue, removeAggregation

We have a choice then:

  1.  change the API of those 4 operations in the same way, to get a more homogeneous API
  2.  keep it as it is now
  3.  revert to a "List<ObjectRef>" API for all operations

My preferred choice is 1. Here is a table to explain the alternatives and help you make your choice:

definitions: List<ObjectRef>

domain: List<Identifier>
keys: List<Identifier>


explicit List of ObjectRef to the Definition objects concerned by the operation

implicit List of ObjectRef to the Definition objects concerned by the operation, built as
- single domain field shared by all ObjectRef
- each key field from the input list
- version field set to 0


pros

standard usage of the MAL v2 ObjectRef

more user friendly? (reason for the WG choice in the first place?)


cons

Gives access to older versions of a Definition object, which is a drawback if this should never be allowed.

Only the latest version of the Definition object is accessible. Operating over an old version is not possible.

cons

More verbose with the possible duplication of the domain field, and the provision of a possibly useless version field

Limits the list to Definition objects that share the same input domain. Operating over objects from different domains would require multiple calls.


Thank you for your feedback.

Best regards,
Serge

--

Serge Lacourte

Directeur general

ScalAgent Distributed Technologies SA

tel. +33 4 76 29 79 81

mobile. +33 6 86 47 41 06
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20231214/7a0cda88/attachment.htm>


More information about the MOIMS-SC mailing list