Update RFC with new learnings #1
Conversation
As promised, I've updated this RFC with my thoughts
| ### Plugin Configuration via Front50 | ||
| In order for Deck to know which plugins it can load, it must have access to some configuration information, including the name of the plugin and where to download the plugin resource(s). | ||
| ### Gathering plugin metadata | ||
| In order for Deck to know which plugins it can load, it must have access to some configuration information, including the name of the plugins that are enabled and where to download the plugin resources (JavaScript bundles, CSS, images, etc). This Plugin Configuration will be fetched from Front50. |
There was a problem hiding this comment.
| In order for Deck to know which plugins it can load, it must have access to some configuration information, including the name of the plugins that are enabled and where to download the plugin resources (JavaScript bundles, CSS, images, etc). This Plugin Configuration will be fetched from Front50. | |
| In order for Deck to know which plugins it can load, it must have access to some configuration information, including the name of the plugins that are enabled and where to download the plugin resources (JavaScript bundles, CSS, images, etc). This Plugin Configuration will be fetched from Front50 via Gate. |
|
|
||
| ## Plugin Development | ||
|
|
||
| Plugin developers should have a development experience that closely resembles development of Deck itself. Spinnaker should provide a plugin quick-start, such as a github repository that developers can clone. This quick start should provide: |
There was a problem hiding this comment.
Spinnaker should provide a plugin quick-start, such as a github repository that developers can clone.
Had not thought about this - do like. Makes sense.
| * Only show this warning if plugins are enabled | ||
| * Give guidance on how to resolve error or look up more info | ||
| * What should deck do if it fails to download a plugin resource? | ||
| * Plugin manifests will contain locations where assets are, but another place may serve them (eg secure artifact store), can halyard help with this? |
There was a problem hiding this comment.
If plugin manifests are being served from front50, I think we could do some stuff on the way out of Gate to ensure locations are consistent (e.g. only show locations that are relative to gate, if that's the direction we end up going for serving plugin assets).
|
|
||
| Well Defined Extension Points: | ||
| Interfaces need to be created for anything that can be extended. | ||
| During Deck's bootstrap, it should call all enabled plugins' `initialize()` method passing in a Plugin API object. This object will expose a set of hand-picked functions that are hand picked for Spinnaker Core and register. |
There was a problem hiding this comment.
If I'm reading this correctly, plugins will still have to register themselves - did you see any way of using an IoC pattern here? From the design doc, we discussed possibly having Deck register plugins it finds (https://docs.google.com/document/d/16WmRSziTJsSBZ1kuKUfVleLAYMIxmfvz/edit?disco=AAAAD8PetDs).
Second sentence has some redundant info, hand-picked / hand picked functions
There was a problem hiding this comment.
I will update this.
My main concern is that some things in deck (especially related to routing) may not be able to be done declaratively and will still require an imperative API such as initialize(). However, I agree it would be better to export an object with (for example) a stages property than have the initialize method wire them up.
As promised, I've updated this RFC with my thoughts