Add SIP for packaging middleware components - #3664
Conversation
Signed-off-by: Michelle Dhanani <mdhanani@akamai.com>
itowlson
left a comment
itowlson
left a comment
There was a problem hiding this comment.
I'm not sure what the status of this is - you didn't ask for review so I apologise if I'm being premature, but I just left a couple of notes as I noticed things. (If you want a Paddington Bear Hard Stare review then of course I'm happy to read through it in more detail.)
| currently be relying on trigger information to efficiently store runnable components | ||
| in an application. An explicit `type` makes intent unambiguous and lets validation | ||
| stay strict for standard Spin apps. | ||
| * **A separate manifest kind / file.** Introducing a wholly separate manifest |
There was a problem hiding this comment.
I think this bears consideration, because one of our goals is to support modularising spin.toml, and @tschneidereit's proposal for this involved component manifests that - although initially shipped as "modules in a spin.toml" - were kind of conceived of as potentially standalone, packageable, distributable components. (The vision is not yet quite in focus for me, so I may be misrepresenting it, but that was my sense from reviewing the SIP and talking to Till about it.) And a middleware component is such a distributable component, rather than an application. It's worth checking out the proposal at #3073: what you have here might be another route to what Till is trying for.
| * **A separate manifest kind / file.** Introducing a wholly separate manifest | ||
| schema for reusable components would fragment tooling. Reusing the existing v2 | ||
| manifest with one additive field keeps `spin build`, `spin registry push`, and | ||
| the component-dependency system working with minimal change. |
There was a problem hiding this comment.
Note that middleware in its current form can't have dependencies.
2 participants
No description provided.