During plugin loading, the plugin name, supported attestation scheme and media
types are used to infer plugin capabilities. The plugins are looked-up based on
these capabilities at run time.
#435 adds a different class of plugins -- store plugins, whose capabilities cannot
be completely expressed using the existing interface. Examples of store plugin
capabilities are:
- supported attestation schemes
- supported CoSERV profiles
- supported operations (read triples, writability, coserv)
Hence the plugin interface should be changed so that store plugins are also
able to advertise their capabilities during plugin loading.
One way to do this is by structuring the plugin discovery message. Instead
of separate GetName, GetAttestationScheme, GetSupportedMediatypes, there
can be a single method GetCapabilites, which returns a structured response
containing all the discovery details. The plugin loader can use all this
information during the loading process.
During plugin loading, the plugin name, supported attestation scheme and media
types are used to infer plugin capabilities. The plugins are looked-up based on
these capabilities at run time.
#435 adds a different class of plugins -- store plugins, whose capabilities cannot
be completely expressed using the existing interface. Examples of store plugin
capabilities are:
Hence the plugin interface should be changed so that store plugins are also
able to advertise their capabilities during plugin loading.
One way to do this is by structuring the plugin discovery message. Instead
of separate
GetName,GetAttestationScheme,GetSupportedMediatypes, therecan be a single method
GetCapabilites, which returns a structured responsecontaining all the discovery details. The plugin loader can use all this
information during the loading process.