Invoking Interfaces + Wrappers/Plugins As Implementations

After thinking some more about plugin/interface/wrapper use-cases when invoking them through the client, I’ve come to the conclusion that the following 2 execution orders should be carefully considered.

NOTE: this is speculative, and the client may or may not function this way.

Case 1:

Calling getImplementations() should return all possible cases: plugin, interface, wrapper. Currently it only returns the registered interface implementations.

The above is useful because:

  • app developers can override an interface by simply adding a plugin at the same URI.
  • wrapper developers can now “get implementations” of all types, and not just the interface implementations.

Case 2:

Calling invoke() should invoke all possible cases: plugin, interface, wrapper. Currently it only invokes plugins and wrappers.

The above is useful because:

  • wrapper developers can now invoke all types of wrappers, including URIs that point to interfaces.
  • invoking interfaces in your wrappers can be made much simpler, and look just like using wrappers & plugins.
  • app developers could add multiple implementations that will override the wrapper live at the specified URI. Since there is no “sane default” for invoking one of the registered implementations, app developers can choose from an assortment of “selection algorithms”, such as: random, round robin, first, etc.
    • These selection algorithms could become super useful in aggregation applications…

Positive Externality

When authoring schemas, we can now pretty much treat all external dependency schemas the same. This could help drastically simplify the schema development experience.