Remove CommonActionTypes from SPI

[jimmarino]

@DominikPinsel @denisneuling Can this be moved to the sample policy module? For example, would we expect all runtimes to support a set of policies?

Typing can be useful but why not at a higher level such as in the IDS modules?

If this should be this low in the hierarchy, shouldn't it go into the policy module then?

[DominikPinsel]

I'm not 100% sure what the sample policy module is, but if its the policy-model extension, then it can be moved there. We created the CommonActionTypes to avoid magic strings in the :samples:demo-contract-framework extension, that creates policies, and the :data:protocols:ids:ids-core extension, that maps this policy to IDS.
Therefore, as long as its part of the SPI and can be used from these two extensions, the policy-model is fine, too.

[jimmarino]

I think it should be moved upstream, e.g. in an IDS module.

[DominikPinsel]

Sorry for the late reply. If we move it to an IDS module, then an extension, that implements the ContractOfferFrameworks, needs to reference IDS to use it for its policies. I think it's better when only IDS extensions reference IDS extensions.

Another thing is, that I assumed the CommonActionTypes.ALL is IDS independent and can be used from the EDC, to allow all kinds of actions. Without knowing about IDS.

In the policy model both, the IDS extensions and the ContractOfferFramework extensions, are able to access the CommonActionTypes.

[jimmarino]

Does the core need to understand what "ALL" is? That seems like an implementation detail of the framework implementation. Let's discuss.

[DominikPinsel]

That's an interesting question. I think the core, as business layer, needs to understand the contract completely. So that the ContractOfferFramework extension can use the Contract model from the core, to describe the "All-Contract" (not only a representation of it). And the IDS extension then, using the same model, is able to understand what an "All-Contract" is.

If we move this out of the core, both extensions would have to agree on some kind of representation for an "All-Contract". If they do it without referencing each other, this results in a hidden dependency between these two extensions. At some point In the future this implementation might break partly or completely, without us noticing. Especially for a large number of complex contract types, which we might have to support in the future.

Besides this, I think there are a number of other reasons against such hidden dependencies. Like a reduction in maintainability or testability.

_{Dominik Pinsel [email protected], Daimler TSS GmbH, legal info/Impressum}

[jimmarino]

I don't think the core should understand anything about the specifics of the contract (it's an engine, not a business layer). It simply needs to transport the contract representation higher up in the extension hierarchy where policies associated with the contract will be evaluated. The policy author can construct a policy that always evaluates to "enabled true", that gets moved by the core up the hierarchy, and the policy engine evaluates it. There could be multiple ways of expressing an always true outcome in policy; the core doesn't need to worry about it since the policy evaluator will take care of that.

I don't see how this is introducing hidden dependencies. I may not be understanding the issue, so can you lay out a concrete example? I may just be misunderstanding the issue.