-
Notifications
You must be signed in to change notification settings - Fork 63
Concepts #15
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
Concepts #15
Conversation
I think for "what is a component" I probably need to stop trying to define what a component is, and instead take the reader on a journey from "what we can do with core modules like you already know about" through "what we can't do with core modules even though it would be super handy" and thereby get to more "what components do for you." Which seems obvious in retrospect but I wish it had seemed obvious a few hundred words earlier... |
Well I am still not very happy with this but am stumped as to how to do better - very open to any feedback (even if it's "bin it all and write this instead"). Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like this! I think we can continue to add to concepts and expand upon it but overall this already unveils a lot of information.
## Worlds | ||
|
||
A **world** is a higher-level contract that describes a component's capabilities and needs. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the worlds you define will be these kind of custom, library worlds.
By "define" are you emphasizing that the components that make up your business logic likely have custom worlds while those exposed to the runtime and host are likely common worlds (that likely live in warg
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was trying to refine Joel's observation that "most people don't define worlds unless they're building an operating system-a-like". I'm trying to highlight that as far as most readers are concerned, they'll only define their own worlds when creating APIs for libraries; for big, common worlds like WASI, they will consume then but not define them. I'll see if I can phrase this more clearly but open to suggestions!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for big, common worlds like WASI, they will consume then but not define them.
I think this is the key. maybe we can just drop this line in, but what you have it modified too is also great!
A **package** is a set of one or more WIT (Wasm Interface Type) files containing a related set of interfaces and worlds. WIT is an IDL (interface definition language) for Wasm. Packages provide a way for worlds and interfaces to refer to each other, and thus for an ecosystem of components to share common definitions. | ||
|
||
A package is not a world. It's a way of grouping related interfaces and worlds together for ease of discovery and reference, more like a namespace. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we have this proxy be a part of our tutorial for continuity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like a semi-realistic HTTP proxy might be too complicated and a simplified one might be unconvincing. Probably it would be better to design the tutorial examples for maximum, er, tutoring, and then cite them here, rather than the other way round. But we can reassess over time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the wasm-tools compose
example is essentially a proxy (called middleware
) and it isn't too hard to understand
@kate-goldenring thanks! I updated (with some advice from @tschneidereit as well) as a separate commit so you can see the diffs (but will squash before merging) |
Merging this with a view to continuing to iterate on it as the book develops! |
This is a first crack at a basic concepts page, though it probably recapitulates the WIT stuff too much. It was originally conceived of to cover things like resources and the capability model, but I think those are out of scope for Preview 2?
I was originally hoping to cover the "What is a Component?" topic as part of this, but after writing and deleting multiple attempts, I have concluded I still have no idea what a component is! This is going to be one of those monad things where as soon as I understand it, I become unable to explain it, isn't it...