You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Extensions should clearly describe the components added by it #9
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
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".
Activity
rwb27 commentedon Feb 15, 2021
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 thelinkswould 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 commentedon Feb 15, 2021
Yeah everything you've said sounds totally sensible. I'd be fine with that route.
beniroquai commentedon Feb 15, 2021
I think that would be a great solution for external hardware resources!
rwb27 commentedon Feb 16, 2021
Cool. I will try to think about this and make a PR. It will take me a while though!