[IDEA] Split API from application

[mgaffigan]

Is your feature request related to a problem? Please describe.
Writing plugins ties you to a particular release of the application. It is desirable not to require such rigid coupling. It's also annoying to build, since Maven Central does not contain API JARS, and encourages use of non-API surfaces within mirth-server.

Describe the solution you'd like
Split mirth-server into mirth-server and mirth-server-core. (Same for client). Publish mirth-server-core to Maven Central. Version mirth-server and mirth-server-core separately (only changing mirth-server-core when the API shape changes).

[jonbartels]

Does this need to introduce anything to the plugin definition contained in plugin.xml?

Do we need to repurpose the mirthVersion field to express the API versions supported? Do we need to deprecate it and add a wholly new field? I see a few options:

1. mirthVersion represents the API versions it is compatible with, the field name stays the same and this makes OIE compatible with older plugins without changes -> I prefer this option
2. Add a new apiVersion field which clearly expresses the API compatibility. If we do this we need to consider either dropping support for mirthVersion or falling back to it gracefully.

[mgaffigan]

@jonbartels, I've not reviewed the code to speak in specifics, but plugins should be ignorant of the server release version. Plugins should only care about the server API version being acceptable, and exposing the plugin version.

Clean-sheet design for me would be:

• Server release version: 1:1 with the git tag of the codebase used to produce installers, used in the UI for "primary" version
• Server API Version: infrequently and manually updated semver describing a change to the API shape or contract
• Plugin release version: 1:1 with the git tag of the codebase used to produce the plugin artifacts
• Plugin API Version: infrequently and manually updated semver describing a change to the plugin's API shape or contract (omitted for most plugins, since most do not expose API's)
• Plugin dependencies: API version ranges deemed acceptable to allow the plugin to operate. Includes the server, but may also include other plugins (e.g.: http depends on httpauth, datatype-dicom on connector-dicom)

I think most of the version infrastructure in the codebase refers to API versions. Release versions are likely something to add.

An example a few years from now:

• Server version: 2028Q3-51897817
• Server API Version: 4.7.10
• Plugin release version: 2027Q4-e4039605
• Plugin dependencies: { "server": ">4.6.7", "httpauth": ">4.7" }

Other benefit of plugin dependencies specifying names is in handling forks. server-oie vs server-foo.

[ChristopherSchultz]

This request ignores the fact that plugins can be either client or server or both. Unfortunately, you can't really have a "clean sheet" design, here. The legacy of MC is that plugins are bound to server version(s). it's going to be very difficult to get away from that.

If the "interface" is Java class interfaces, then there is nothing to be done: your choices are to freeze those interfaces forever or bind to some kind of (server) version. If you want to change the "interface" to be "JSON stuff" then you can just throw up your hands and say "if it works, it works" and let plugins and server components fend for themselves.

I myself would (a) stick to Java interfaces, (b) freeze the current interfaces forever except that any future changes would need to require default implementations -- which weren't available when MC was first introduced -- and (c) kind of run out of ideas when new interfaces would be required.

How does a plug-in advertise which interfaces it needs? I suppose you could seriously augment the plugin.xml format, but then backward-compatibility isn't great. Having nice defaults... eh, okay, but super surprising. "Why is the default mirthVersion set to 4.5.2 instead of 1.0.0?" Insert awkward answer.

Look to Microsoft COM and e.g. DirectX for an example of how insane this can get. You have to end up implementing a meta-language just to negotiate what will and what will not run.

[mgaffigan]

This request ignores the fact that plugins can be either client or server or both.

I'm not sure what problem you're referring to here.

If the "interface" is Java class interfaces, then there is nothing to be done: your choices are to freeze those interfaces forever or bind to some kind of (server) version.

No changes are proposed to the interfaces themselves.

The normal model here when changes occur is to:

1. Avoid ABI breaking changes (e.g. default implementations)
2. Add a versioned interface, leaving the legacy behind
3. Take a breaking change

The point is that the server version and the API version are different. Most plugins have not needed a version change in ages, they just do it for because they have to.

How does a plug-in advertise which interfaces it needs?

No changes to interfaces or discovery are proposed, only to plugin.xml to add support for dependency version assertions.

Look to Microsoft COM and e.g. DirectX for an example of how insane this can get.

I don't follow. I have many problems with COM, but interface versioning is not one of them.