Extensions should clearly describe the components added by it

[jtc42]

Depends on #6

Extensions overview will show extension metadata, extension views, and extension components. This is extensible for anything else we might allow extensions to add in the future

[rwb27]

I was thinking some more about this. Would it be sensible to generate Thing Descriptions for each extension? That would feel nicely standards-compliant, and solve a couple of problems. That way, if you go to /extensions/ one of the links would be to a Thing Description (rather than the links being the actions/properties), which feels more like how this ought to work.

It also means that extensions are Things, and we could use semantics to help with a more general plugin architecture. For example, if you have an extension that declares itself to be an XYZStage (in the OpenFlexure namespace), we could then use it instead of the SangaStage (indeed you could imagine implementing the current stages as default extensions, and allowing a new extension to provide a different driver that's picked from microscope_configuration.json).

If I've understood correctly, I don't think this should be an insurmountable challenge, and I might even attempt it at some point. I think it could be a nice solution to how we implement alternative hardware wrapper code, and it's "WebThings all the way down".

[jtc42]

Yeah everything you've said sounds totally sensible. I'd be fine with that route.

[beniroquai]

I think that would be a great solution for external hardware resources!

[rwb27]

Cool. I will try to think about this and make a PR. It will take me a while though!