<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear all,</p>
<p>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.</p>
<p>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:</p>
<ul>
<li>Parameter: getReportingConfiguration, enableReporting,
disableReporting, setReportingPeriod</li>
<li>Alert: getAlertConfiguration, enableGeneration,
disableGeneration</li>
<li>Aggregation: getReportingConfiguration, enableReporting,
disableReporting, setReportingPeriod</li>
</ul>
<p>It looks now inconsistent with a few other operations, which
still use a List<ObjectRef> parameter, namely<br>
</p>
<ul>
<li>Parameter: getValue, setValue</li>
<li>Aggregation: getValue, removeAggregation</li>
</ul>
<p>We have a choice then:</p>
<ol>
<li>change the API of those 4 operations in the same way, to get a
more homogeneous API</li>
<li>keep it as it is now</li>
<li>revert to a "List<ObjectRef>" API for all operations<br>
</li>
</ol>
<p>My preferred choice is 1. Here is a table to explain the
alternatives and help you make your choice:</p>
<table width="100%" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top"><br>
</td>
<td valign="top">definitions: List<ObjectRef><br>
</td>
<td valign="top">domain: List<Identifier><br>
keys: List<Identifier><br>
</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top">explicit List of ObjectRef to the Definition
objects concerned by the operation<br>
</td>
<td valign="top">implicit List of ObjectRef to the Definition
objects concerned by the operation, built as<br>
- single domain field shared by all ObjectRef<br>
- each key field from the input list<br>
- version field set to 0<br>
</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">pros<br>
</td>
<td valign="top">standard usage of the MAL v2 ObjectRef<br>
</td>
<td valign="top">more user friendly? (reason for the WG choice
in the first place?)</td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">cons<br>
</td>
<td valign="top">Gives access to older versions of a
Definition object, which is a drawback if this should never
be allowed.<br>
</td>
<td valign="top">Only the latest version of the Definition
object is accessible. Operating over an old version is not
possible.<br>
</td>
</tr>
<tr>
<td valign="top">cons</td>
<td valign="top">More verbose with the possible duplication of
the domain field, and the provision of a possibly useless
version field<br>
</td>
<td valign="top">Limits the list to Definition objects that
share the same input domain. Operating over objects from
different domains would require multiple calls.</td>
</tr>
</tbody>
</table>
<p>Thank you for your feedback.</p>
<p>Best regards,<br>
Serge<br>
</p>
<pre class="moz-signature" cols="72">--
Serge Lacourte
Directeur general
ScalAgent Distributed Technologies SA
tel. +33 4 76 29 79 81
mobile. +33 6 86 47 41 06</pre>
</body>
</html>