sip: Update SIP 005

[lann]

No description provided.

[lann]

We already renamed this key, separately.

[lann]

I don't think this is actually a viable option.

[radu-matei]

+1

[michelleN]

• Would it be possible to move trigger information into the component trigger section?

• I'm for removing base but could we call out why folks would want to use it? I'm still not super clear on why someone would want to use base over adding that to the path by hand with Spin.

[lann]

I left out a bunch of changes that I meant to include, now added.

[lann]

I'm still not super clear on why someone would want to use base over adding that to the path by hand with Spin.

Me neither...

[mikkelhegn]

Should this be handler_component? Handler makes sense, because that's what it does :-), but below the proposal still refers to it as a component [component.world].

[lann]

Sure, it could be. Just a tradeoff between being concise and being explicit I guess 🤷

[mikkelhegn]

I think it makes it easier to talk about if it's explicit.

[radu-matei]

Opinion alert: I don't think there is a danger of confusion with just handler.

[fibonacci1729]

+1 to @radu-matei ....want to avoid component studder everywhere.

[mikkelhegn]

Can you elaborate on that Brian? Are we trying to get rid of component as a Spin concept, and/or align with webassembly concepts and/or wasi-http concepts?

[fibonacci1729]

I think what motivates my lean towards the concise here is that conceptually a trigger, as modeled in WIT (or generally as a component), might import an instance of whatever http component (hello in this example) and that import name expressed in WIT might look like import handler: ... or import fermyon:spin/handler. You probably wouldn't say in WIT import handler_component: ....

I definitely tend to prefer explicitness but in this case (albeit without great justification) I lean towards the concise I suppose. Seeing *_component throughout a larger example manifest would be hard on the eyes, me thinks.

This is not a hill I'm willing to die on though.

Alternative suggestion, what if we named the field simply component which would ameliorate the concise vs explicit tension (which sort of destroys my previous argument 🤣).

🤷‍♂️

TL;DR: lazy engineer want type little chars possible. 😋

[mikkelhegn]

Thanks for the input. Rereading the combined example, I can see how the 'handler' as part of a 'trigger' section, as a reference to 'who is handling this trigger' (which is a reference to a component; either inline source, or a 'component' section.) is easy enough to explain. Thx!

[mikkelhegn]

Why does the proposal want to allow this?

[lann]

It keeps the manifest smaller and linked component/trigger configs visually close together.

[mikkelhegn]

LGTM

[rylev]

🎉 +1000

[karthik2804]

Does this issue discussion come into the scope of this PR as well?

[lann]

Does this issue discussion come into the scope of this PR as well?

Not necessarily: it looks like the proposal there would fit into either a v1 or v2 manifest in pretty much the same way.

[michelleN]

All of these changes look great. The only thing I'm a little confused about is generated IDs. Can you expand a bit more on that? What is generating these IDs? What does that experience look like? Why would you go for using generated IDs?

[lann]

generated IDs

Generated IDs would only apply to "inline" component defs like

[[trigger.http]]
route = "/hello"
handler = { path = "hello.wasm" }

In this case the trigger doesn't need an explicit component ID to reference, but we might still want the component to have an ID for things like #1116.

I think we can leave the exact generated IDs up to the implementation but I would imagine something like inline-1 or maybe something more clever like inline-hello.