Feature/ssp-pluggable-algorithms

[markaren]

This PR adds a plugin based system for parsing algorithms, modeled after the model_uri_resolver.

Since the load_ssp function needs yet another paramater for this to work, I decided to wrap this function in a statefull class named ssp_loader. This greatly simplifies usage.

cse::ssp_loader loader;
ssp_loader.set_override_algorithm = ...
ssp_loader.load(xmlPath);

Closes #437
Blocked by #447

[kyllingstad]

I like the general idea of this. I'm just worried that it's a bit premature. It adds a lot of machinery to enable pluggable algorithms, when the fact of the matter is that we only have a single algorithm to plug in yet, and it's built into the cse-core library.

[markaren]

It adds a lot of machinery

I wouldn't say a lot. The ssp_loader class should be added regardless and can therefore be overlooked in this respect. I could even make yet another PR.

when the fact of the matter is that we only have a single algorithm to plug in yet, and it's built into the cse-core library.

I'm just worried that it's a bit premature

I think you agree that both the SSP parser and cse-config parsers must have this feature. We can rather discuss how it should be implemented than saying we do not need it right now.

A core issue with the current state of the SSP and CSE-config setup is that they are not fit for the future. Meaning they are bound to introduce breaking changes in the future. My recent PRs try to remedy this. At least for the SSP one. Then the CSE-config must catch up somehow.

[kyllingstad]

I think you agree that both the SSP parser and cse-config parsers must have this feature. We can rather discuss how it should be implemented than saying we do not need it right now.

Sorry, I didn't mean to come across as negative. It's just that this comes without any prior discussion of either requirements or design (at least that I can remember), so these discussions must be had here and now. And in my mind, requirements must come before design.

Your design is nice and the code looks good. My point was that we don't know the requirements yet.

A core issue with the current state of the SSP and CSE-config setup is that they are not fit for the future. Meaning they are bound to introduce breaking changes in the future. My recent PRs try to remedy this. At least for the SSP one. Then the CSE-config must catch up somehow.

This does not prevent any breaking changes in the future. What if we decide to encapsulate algorithms in some FMU-like container (or just plain DLLs)? Then we need a URI (or at least file path) resolver, not a name resolver, and the XML structure in #447 would look very different.

As long as we hard-code the algorithm name in the XML schema, we might as well hard-code it in the C++ code.

I am fully aware that I tend to overthink things and let perfect stand in the way of good, though, and maybe I'm doing that here. You should probably wait for comments from the others and not listen too much to me. ;)

[markaren]

It's just that this comes without any prior discussion of either requirements or design

True, although the requirement has always been for core to be plugin-based. But I agree this does come out of the blue.

As long as we hard-code the algorithm name in the XML schema

This PR does not use Algorithms names in the schema. Though it defines a schema for the FixedStepAlgorithm.

[kyllingstad]

Doesn't this correspond to an element name in the XML schema in #447?

[markaren]

What I meant is that the xsd does not specify any algorithms.

 <xs:element name="Algorithm">
        <xs:complexType>
            <xs:sequence>
                <xs:any processContents="skip"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

[markaren]

But we can put this on hold for a little while. Whats most important for me is to get #447 merged/approved. Been waiting a looong time for that.

[markaren]

Closing for the time being. Better revisit in the future.