IPlugin Requirements

On this page the specification of a new IPlugin interface is worked out.

Qualitative requirements

• What IPlugin developers expect:
  • lean, easy to implement interface.
  • relief of the plugin from all functions that are not part of the immediate plugin functionality
  • no code blocks that are repeated in several plugins
  • clearly defined and intuitive function of all components of the interface (each function should be free of side effects and not tempt to abuse to implement another function)
• What is derived from the requirements for the visual programming language as well as the execution engine:
  • fast passing of input and output parameters.
  • support of arbitrary data types
  • clean separation of execution and visualization

Functional requirements

• Output parameters should be prepared/supplied only when needed. Example: ICryptoolStream and byte[] as output parameters. If only stream output is connected, no need to create byte[]. (demand-driven)
• No processing should be needed on input parameters, e.g. plugin developer should not need to run OnPropertyChanged for QuickWatch update on input parameters, as editor/execution engine can communicate it among themselves without going through plugin.
  • Conceivable: Plugin programmer could be expected to consume input parameters manually (flow control of execution engine). This depends on whether there are useful use cases versus automatic consumption of input parameters by the execution engine.
• QuickWatch should work automatically on all data types via ToString(). IPlugins are not responsible for converting data types to a QuickWatch view.
  • Conceivable: An interface IQuickWatch with method ToQuickWatchString() for complex, specially defined data types.
• If dynamic elements are still necessary (dynamic properties, dynamic settings), they should be implemented without the indirect 'method name as string -> method' referencing.
  • It is crucial a) that there is either a single place to change, or b) that there is already an error at compile time if you forget to adjust a place. The error should not be noticed at runtime.
  • Cf. problem with Dynamic Combobox: as cast -> returns null. Wrong return type is not caught and triggers error in CrypWin.TaskPaneCtrl.AddOutputControls (for DynamicComboBox -> inputControl is null).
  • Possible implementation: method call AddDynamicProperty(THIS_IS_A_CONST_KEY, new ValueObject()). To get type safety with generic get/set methods, you would have to work with generics. Is not 100% safe, but covers most error cases.
  • What are the use cases for dynamic element? Is it possible to do without them altogether, e.g. by using another feature (e.g. Visibility Toggle)? Dynamic elements make plugin design more complex due to indirection and should be avoided unless absolutely necessary.
  • Dynamic settings necessary?
• The plugin must be able to distinguish in the input parameters, ...
  • whether a data input is connected or not (so far: is null? see also #81)
  • whether a date is connected to an input or not (so far: is null?)

Requirements for settings

• Order of the settings results from the natural order of the properties in the code (no order parameter) -> already checked, not possible, because .NET does not guarantee an order of the attributes.
• HasChanges is handled automatically and not in every plugin separately -> already implemented