-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Questions on URLs in imports/exports #130
Comments
Great questions! Answering point-wise:
|
Hm ok given all that I fear that I'm losing sight of the motivation of URLs and how everything is supposed to stack up together. Everything seems to favor using the URL but falls back to the kebab-name, so why not require URLs? Additionally why not go a step further and replace kebab-names with URLs where a bindings-generated-name could be something like that last element of the URL, or otherwise have the bindings-relevant pieces in other unrelated sections. For example:
This sounds like from an engine-implementation perspective that the kebab-names effectively don't matter, instead using URLs-falling-back-to-kebab instead. That's at least not what I was expecting and would require some significant rework of the ergonomics and planned idioms for how to create and use an embedding API.
I just had to audit/vet 100kloc for Rust for the inclusion of the While I understand the desire for "let's not have random strings" I at least personally can't really fit this into my mental model of how everything is going to work. If everything validates URLs everywhere I'm having a tough time reasoning out why it's worth it other than "well it's good to be well-formed, right?" in the sense that the well-formededness doesn't seem to be buying any concrete features at this time.
Given what you're mentioning I'm not sure why this is any better than "what if we just had urls" or "what if we just had kebab names". I was under the impression that with URLs some of this would be more automatic (somehow, I never thought that hard), but given that collisions always require manual work I'm not sure why we'd have the possibility for collision in two places.
This is at least not what I was personally expecting, and this provides more fuel to the fire of "why have kebab names in the first place?" in my opinion. If the URL is what matters why not have only the URL? I'll admit I did not try to think through all these questions before URLs were landed, I'd sort of just assumed it was all already figured out. But looking at it now I'm questioning more why we have both kebab-names and URL names. They seem to both be pulling in different directions a bit. Personally my mental model of everything would make more sense with something along the lines of:
or the alternative of no URLs and going back to just kebab-names everywhere. I don't have a strong grasp on the original motivation for URLs, however. |
It's a valid question to ask why have both. To start with, I think there are a number of simultaneous things we want here for a good DX:
Automatically deriving kebab-names from URLs by parsing out parts of the URL is an interesting option to consider but:
Putting kebab-names in separate custom sections is also an option to consider but since these kebab-names go into the actual source code of client code, and these bindings are sometimes generated live by the runtime, this seems to go against the idea that custom sections are semantics-free and can always be stripped: stripping a custom section shouldn't break running code. If we make special rules about these custom sections, it's not clear how this would be meaningfully different than what's proposed other than binary layout. If the complexity of |
Implementing #109 in Wasmtime I'm not 100% sure how the new URL fields should be exposed/accomodated through the embedding API, so I wanted to as a few (possibly simple) questions here:
Should the URL be used when linking a module together on the host? For example right now in Rust you can insert named functions into a
Linker
type, optionally within a nested "instance" which is just a bag of named functions. Should the URL, however, factor into the host-side linking? Similarly is this expected to affect how exports are accessed?Orthogonally, is there an intended use case for these URLs which requires them to be valid? Adding a URL parser to a low-level validator adds a somewhat weighty dependency to a low-level component, so if it's possible to defer the URL validation to later that would be nice, but only as a nice to have and not necessary.
IIRC one of the purposes of URLs was to merge worlds together, and if so this doesn't seem like a trivial operation to me so would it be possible to write up some pseudo-code and/or words about how this is expected to work? (e.g. what to do with different-name same-url imports or same-name different-url imports.)
To confirm, URLs don't have any affect on validation other than uniqueness and it's-a-url-ness, right? That is, they don't play into "type matching" when validating that a component can be used to satisfy a component import?
The text was updated successfully, but these errors were encountered: