Transcript: wasmCP MCP Servers & Long-Running Services on the Wasm Component Model
wasmCloud Weekly Community Call — Wed, Oct 22, 2025 · 62 minutes
Speakers: Brooks Townsend, Corey, Ian, ossfellow, Frank Schaffa
Transcript
Brooks Townsend 02:33
All right, let's get the thing going, and then I have your description here. All right. Hey everybody, welcome to wasmCloud Wednesday for Wednesday, October 22. We've got a pretty exciting demo to start the call from Corey, who's going to be demoing wasmCP, which we talked about in the call a little bit over the past couple of weeks. So WebAssembly component development kit for the Model Context Protocol. Corey, I don't actually know if you did an introduction the other day — I know Ian did, right at the start of the call. Would you like to start by maybe just doing a little quick introduction for yourself, and then I won't over-prescribe; you can go right on to the demo.
Corey 03:28
Yeah, absolutely. So Ian and I were previously co-workers at Extend, a startup — it's been like five years now, or, I mean, we spent five years there. I was the founding DevOps engineer, and basically spent the last four years building out their infrastructure-as-code serverless platform. And then Ian and I had a harebrained idea related to AI, and, you know, a couple months later, here we are.
Brooks Townsend 04:02
Right on, yeah, awesome. Well, excited to see it. I think you should be able to share.
Corey 04:07
Yeah, I am. I had to go through and make sure I could actually — all right, Ian, am I actually sharing my screen? The typical start of a —
Brooks Townsend 04:29
Well, I can see VS Code.
Corey 04:35
Yeah, perfect. So wasmCP, like we were saying, just aiming to be a framework for building MCP tooling, resources, prompts, etc. And so the idea here is we'll basically start from scratch, essentially, so we will scaffold out a new tool. Right now we've got Rust, Python, TypeScript that are working — a bunch of templates that can quickly scaffold out the tool. Hopefully this works. Sweet. All right, so demo — that's essentially the name of the tool — provides a basically out-of-the-box set of tooling that you can use just sort of as an example and reference point. So you can see here, you know, a couple of tools: add, subtract. We can, if we copy —
Corey 06:01
Going to do my best to use wash for all of this. So it builds with wash, also just builds with all of the normal sort of Rust tooling — produces the binary with our tooling in it. And then with — we've got a compose function that basically wraps a lot of it in our framework, essentially a lot of the related tooling to handle the MCP-related stuff. So that produces the final binary. You can run it with Wasmtime, Spin, or wash. And I've got a helper tool I wrote to start a lot of the wash stuff up.
Corey 07:24
All right, cool. So it should now be running. I believe I tried to get some of this stuff done ahead of time. So you can see, here's our demo MCP server, a couple of tools. You can call them as normal. Prove it actually works. Cool, right? So it calls our add tool, away we go. So then if we come back, you know, this is pre-canned stuff I added just to not spend too much time writing code.
Corey 09:37
So I had some pre-canned, you know, adding two more tools — squaring numbers, square root. So now we can go back, do another build, compose. Now, in theory, if those went as planned, if we reconnect, you can now see we have four tools. So we've got square, square root. And that's essentially the local development flow. I mean, it's as easy as defining your business logic — your input schema, options, etc. — and then just the code. So you're basically not responsible for pretty much anything outside of "this is what I want to make go." In addition to building and running this stuff locally, we just push and stuff. And I don't think I have anything published that will technically work — we can give it a shot, though.
Corey 11:51
Helps to spell things correctly. We also have some helper functionality built into the tooling. So rather than necessarily having to copy around a bunch of paths or OCI references, etc., we have some basic aliasing that you can use. So you can see here, I've got a couple of aliases pointing to various paths. So this can be a local path, it can be an OCI reference, etc. So then we'll see if this works. If not, we'll call it the demo gods.
ossfellow 12:37
Demo gods, Ian.
Corey 12:51
Yeah, so I thought, oh, we'll see if we can get something published real quick. One more shot, and then otherwise, we'll just have to take it on faith. Anyway, like I said, we pushed a bunch of new — we sort of finalized a lot of the WIT, and the common packages that we built have not been updated yet. But essentially, you can compose a number of items together from these local paths. So you can essentially do, say, compose my local file, the OCI reference of my published commonly available packages, etc., and basically get the resulting MCP server with those tools. Given that the pre-composed stuff is not working, let me grab the — we'll just outline it here.
Corey 15:45
So one of the others — we've been calling it middleware, but that's not necessarily correct naming. I think we're calling them composed tools. But one of the more interesting patterns that we've put together that this allows for is, in addition to being able to call those tools directly, you can also build out these middleware patterns. For example, I've been using the Pythagorean theorem as a good example to outline it: in a given set of functionality that you put together in an isolated component, in addition to the normal handling of a tool, this sort of sits above the level of the tool that we put together for, say, adding and subtracting. When it receives a tool call, it can decide what it wants to do — if the tool request name is for, you know, pythagorean, it will handle the call. And if not, it just hands it off down to the next component in the chain, which, again, when you compose these together, you imagine it just goes left to right as the call flows through the various tooling.
So in this case, it's like, "all right, this is a tool I care about. Where is the code? Here we go" — typical parsing of the arguments. But you can see here we can actually call downstream tools. So in this case, it's like, "cool, I need to square the number," so it calls downstream to the square tool, gets its response, stores it, then squares both numbers, gets the results, calls the square root tool, gets its response, and then returns its response, giving you the hypotenuse. Which means that you can build out these tools in such a way that you could call the square tool directly from your server, or you can use these composed tools to abstract functionality — to where we could get it set up in such a way that it just doesn't expose, say, the square or square root tool, and only shows the Pythagorean theorem tool to the AI client. So it's a good way to build out functionality in a composed, reusable way, and then decide how much of that you do or do not want to expose to the AI. You could pre-compose this as a component on its own and publish that alongside the more lower-level tools.
Corey 19:47
All right, we'll call it demo gods. But anyway, we wanted to show a bit more of this actually working end to end. But that's essentially it. So you can imagine that some of the power here is being able to write a tool once and be able to reuse it, reference it, etc., as needed in these MCP servers, to quickly build out tooling. Because one of the other patterns that we've been looking to play around with is — you could imagine that you can almost dynamically, on the fly, compose a lot of this stuff, given that these are all just published OCI artifacts, to quickly build out or test functionality. And again, in such a way that you are essentially just responsible for writing your business code and business logic without necessarily needing to know anything about MCP, how to use it, stuff like that. We're still sort of in the early days of this, but you can imagine being able to build out a lot of these very useful functional tools to power AI applications — with WebAssembly and this pattern really setting the bar for real-time AI applications that are likely to have a lot of these latency-sensitive requirements. So yeah, that's largely it. Happy to step through or go into more detail as folks would like. I know I sort of ran through a lot of that, but that's largely it — it's just a very quick and easy way to start getting up and running with MCP, on WebAssembly, on pretty much any runtime.
Corey 22:19
Trying to remember, because — yeah, I have this working with, I mean, it works with Wasmtime. You can see that most of what I've been doing has been with wash, but I also have it working via Cosmonic Control. And I don't remember my own tool — does it work? Let's see if it can actually work. Docker's not running, good times. Anyway, while I run through this — if there are any questions, etc. — but it basically runs on pretty much any Wasm-supported platform at this point.
Brooks Townsend 24:13
Yeah, Corey, I saw that you are in the WIT — I guess it was just like a single export of an interface. What happens — we were talking about it a little bit in the side chat — but how does that actually run in all the different runtimes, like Wasmtime, Cosmonic Control, if this is a totally custom interface?
Corey 24:38
So this interface — I mean, this is essentially the WIT that you're required to write. This is like tools, and we've got resources working as well. But it's basically that if you wanted to use resources, you import resources; if you want to run tools, you import tools. And then all of our WIT stuff is essentially what wraps all of that and handles all of the exposure for these various runtimes. So you can see we've got the various protocol stuff — the MCP-related stuff and typing. And you can see this is where we sort of import and export handlers. This handles the middleware chain, which is what allows the composition, where each of our — the wasmCP compose functionality is essentially what goes through and identifies whether you've written the middleware (again, if you wanted to intercept or compose tooling) — imports and exports. If it's a tool, it just exports that tool handler, detects that, and wraps it to eventually get to handling the streams, the incoming handler, stuff like that.
Brooks Townsend 26:39
Okay, yeah, I think that makes sense. So you have a whole representation of the MCP protocol, types and stuff, in WIT, and then I assume there's a WASI HTTP component that you've got somewhere, so that Wasmtime can just run it using — what is it — the streamable HTTP transport? Or are you doing it all over standard in, standard out?
Corey 27:09
No, I mean, this is absolutely using streams and WASI HTTP. You want —
Ian 27:17
Me to talk a little bit about this part? I could share for a second too, just to feel like we're over that article. Am I allowed to share?
Corey 27:34
Should be able to be fine. If not, I can always —
Brooks Townsend 27:44
Don't do it, Liam, don't do it. Shoot, Corey, I feel like I had another question.
Ian 27:55
Darn it. Well, wasn't fast enough.
Corey 27:59
Hold on. I think I just granted Ian permission to share.
Ian 28:12
The idea with the WIT generally is that there are two packages published here: there's the protocol package and the server package. In the protocol package, this is what you are generally implementing, like Corey showed you — if you're implementing an individual feature per server, like tools, resources, and prompts. And that's because this package is, like you said, Brooks, basically a direct translation of the MCP protocol types, painstakingly by hand — in split screen here — so that if you want to implement a different kind of framework architecture using these types, you at least have this published. These are ripped straight from the MCP spec. So if you don't like how we've implemented the actual underlying framework idea here, you can do it yourself without having to rewrite or copy and paste all these, you know, thousand lines of types, basically. And then the features here are the same thing — these are the signatures from the methods in the MCP spec.
And then this server package is essentially the implementation layer. This is essentially what Corey described as wrapping the business logic functionality that you implement into these middleware handler chains. It works kind of like this framework called Middy for Lambda, which is essentially that you can, for serverless architectures, define basically the full functionality of your application middleware stack the whole way through. And so that's kind of the idea here. And then — you'll notice, Brooks — for WASI HTTP, our transport contract is just that it imports the handler. So we didn't want to encode a specific transport; you just have to satisfy this transport contract via whatever transport types you want to implement. So you can implement this with different versions of HTTP, you could implement a WebSockets transport — all the transport has to do is handle message framing and then call into the underlying stack. So where the HTTP is, it's actually in-crate. We have one transport world but two transport components: an HTTP transport component, which includes the transport world we just saw and also the WASI HTTP proxy. And for the standardized transports, it's similar, except it includes the WASI CLI command. So if MCP decides to include a WebSockets transport, we can support that without really having to change the contract of our WIT. And as far as I understand it, gRPC for wasmCloud could be possible via a similar idea, I hope. Yeah, that's all I wanted to share about that.
Brooks Townsend 31:17
Yeah, super cool. It's just cool to take a look at how you guys have structured the WIT and kind of made it transport agnostic. That's really, really nice. You just get your generated bindings from wasmCP and write your tool, right? I mean, that's kind of it.
Corey 31:37
Yeah, that's exactly it. You scaffold out a tool, and again, it's "here's my business logic, here's my input schema," and away you go.
Ian 31:49
Generally, how the MCP server SDKs work is that you just have to define the tools, resources, and prompts you want, and the framework takes care of the rest. And this is essentially that same idea, but implemented first-class on components — leveraging components on purpose, because it ends up with the type of architecture that, like Corey showed, you can compose on the fly. You know, components, different tools, resources, prompts, written in different languages, all composed together. You can also save sets of them — like if you were to squish Lego bricks together, you have one Lego brick you just carry around and squish with other things. And also, the goal is to support the full MCP stack. So right now we support a lot of cool features, like SSE streams — from within your tool call, you can send a notification via SSE to the client ahead of the final results. This is also what allows for things like elicitation, which we're still in progress on; an example of that works in a similar way. The idea is that this should be a first-class MCP SDK, but built on components, and it could end up being a really, really good SDK. It's definitely fun right now.
Brooks Townsend 33:05
Yeah, sorry, last thing, and then I'll stop monopolizing all the time. I could totally see this being something like — you could publish an MCP SDK that, when you compile with the wasm32-wasip2 triple, you get all the component bindings, and when you compile normally to the native target, you just get a REST binary, and it all works the same. Maybe, I don't know.
Corey 33:33
I played around with that pattern, but it just wound up being one of those things where, if you wanted to just use native Rust, you're almost better off just using the Rust WASI thing like rmcp, or whatever — just the official Rust crate. Because wasmCP has an MCP serve — we built it because we're playing around with implementing resources as a helper. You can imagine running wasmcp mcp serve, and that exposing all of the context necessary for Claude to use wasmCP to build out tooling, or how to use it, etc. I kind of have it working, but it was a case of "just use the Rust crate" rather than trying to make the WIT stuff work that way. But anyway, pretty fair.
Brooks Townsend 34:34
Yeah. Will folks have questions for Corey and Ian? I see ossfellow — do you have a question? I can read it, or you can go for it if you want.
ossfellow 34:48
I'm just asking, what version of the spec is covered by the current version of it? Okay, thanks.
Ian 34:58
The previous, the 0.3 March release. I've tried that with a client that only supports it, and it should work — the negotiation done by our transport component should work with either the current release or the previous one. And then, obviously, I think there's another MCP release coming out next month, in November, so we're going to be supporting both.
ossfellow 35:21
Yes. It could be useful, either in the README or in the header of, let's say, the MCP WIT or something, mentioning what version of the protocol — so users would know what version of the spec they're adhering to.
Ian 35:42
That totally makes sense. We'll add that. Thanks.
Brooks Townsend 35:48
Pretty cool. I feel like you guys probably have a fun ability to adapt people forward to different versions of the MCP spec, too, feasibly. I know you said you're going to support both in parallel, which makes a lot of sense, but if there's a breaking change later —
Ian 36:05
Yeah, that's the idea. And I think that's what a lot of the frameworks try to straddle, with varying degrees of success, because it can get confusing when you see, "oh, I can add this new field," and then nothing happens when you do. So we'll see. But yeah, MCP is changing all the time — it's probably going to look very different a year from now than right now. And all the coolest features of MCP — the real value proposition is in the bi-directional, dynamic interactions. Clients are only just now starting to support things like elicitations and dynamic tool sets via list-change notifications. That's what I think makes MCP cool. I don't think MCP would be as compelling if it was just a basic tool-calling protocol, and I think a lot of MCP implementations right now basically assume that's all it is. So a real goal here is that, in addition to being able to support the new specs, we want to be spec-complete, at least in terms of what you can implement. Anything you should be able to do with an official MCP SDK, you should be able to do with wasmCP. That's the idea — parity.
Corey 37:23
And to go back to the upcoming spec and stuff like that — you can imagine that some of the flexibility in the way that we've built this pattern out means you could have multiple components handling specific spec implementations. We could compose three different sets of functionality targeting different specifications. And there's so much power in that, just from being able to support multiple specs, easily compose them all together, and abstract that from the user. In the same way, I've been playing around with the idea that you could do almost like A/B testing between component A and component B via the middleware pattern, routing between one or the other. So there are certainly some other interesting ideas out there from what this enables.
Ian 38:36
Not to mention just using WASI proposals and stuff — the fact that you don't see, like, Redis in here, but you're going to be able to manage state via WASI keyvalue that may be backed by Redis, wherever you're pulling it in. By building on components, I think — Liam had mentioned it in this recent video — it's just continuing the trend of platforms and technology to push more of the weight into the platform. So you can just get this one component, and you can drop it into Cosmonic Control, into wasmCloud, or into any other component runtime. And because it targets — it's just a binary that can run with Wasmtime, which is the embeddable component runtime — it should be quite portable across all of them. So if this doesn't work for you, trying it out on anything with Wasmtime inside or Cosmonic Control, definitely reach out to us, because it should work. Any other questions or anything?
Brooks Townsend 39:44
Speak now or forever hold your peace. Well, Corey, Ian, thank you guys so much. I'm sorry — if you want to do a little outro? Thank you guys for coming on and doing the demo and talking a little bit about the project. It's always — I'm glad you were able to get it working on wash, very cool, and Cosmonic, that's awesome. But it's just always cool to see new Wasm component use cases popping up, especially some of the bleeding-edge stuff like running MCP servers, and to see you guys just kind of crushing the Wasm value prop. It's really neat.
Ian 40:32
Hopefully there's more component SDKs like this. I think that idea of a framework implemented via components is a pretty general idea, and hopefully, especially with WASI P3, it's going to be a really cool thing. We're excited.
Brooks Townsend 40:50
Yeah, all right. Well, I know that you guys dropped a couple links in the Zoom chat, but just for anybody who's looking for this: if you go to github.com/wasmcp, that's where the project is. And it looks like you guys have most of your examples, and the whole thing, in that wasmcp repo. So go check it out.
Cool. Well, I guess I have a much shorter and less impressive — but still fun — demo. It's a cool concept that we're introducing that landed in wash, that folks I think are going to be pretty interested in seeing. And it might even have a little integration with wasmCP, like the standard-IO transport option, so you all might like to see it. Let me go ahead and share my screen. You only get demos today.
So one of the things people have asked about for a little while in wasmCloud is a cron capability provider — some long-running process that can call components on a timed interval to execute a job, you know, something once a day or once an hour. It's such a small, simple piece of logic that it really should be able to run as a component — something that's kicking off jobs on a certain interval. And something we couldn't really do in wasmCloud until today is run components that are long-running and have a longer lifecycle than just "receive an HTTP request, hand back an HTTP response." All the components that ran in wasmCloud were short-lived and reactive. Now we actually have a notion in the workload API and the wasmCloud runtime — or in the, well, I'm dubbing it the wash runtime now, but naming aside, we're just bad at it — that is called a service. A service is not a reactive component, not one that, say, like an HTTP counter here, receives an HTTP request and needs to hand back an HTTP response. Services are components that target the WASI CLI world, which in Rust, for example, just compiles straight from anything that is a binary target, like a main function. So services are components that can be long-running. They execute for the duration of their main function, like a process, and then when they exit, they're done.
Brooks Townsend 44:00
That lets us, for the initial couple of examples, do pretty interesting things, like a cron service. I'll show you the workload setup in a second, but I have two WebAssembly components. The first one is this cron service, which — if I inspect it — is in crates/wash-runtime/tests/fixtures. If we inspect this component, we know that it just exports wasi:cli/run, and then has a couple of other imports, but one import for a custom interface, wasmcloud:example/cron. So this component just runs the main, prints something to standard out, and then loops forever — every second it's going to call this function, wasmcloud:example/cron invoke. Now, if you just tried to run this straight up in Wasmtime — you do a wasmtime run — then it'll fail to instantiate, because it doesn't know what this import is. You're calling some import from the host that Wasmtime doesn't know anything about. But I do have this cron component, and this implements the other side of that interface — it implements this invoke function, and every time it's invoked, it just prints to standard error, "hello from the cron component." That's it.
Brooks Townsend 46:00
So the WIT is mega, mega simple. We just have one interface, cron; the service world imports it, and the component world exports it. So this is something you could just compose directly together with wac or the component tooling, and then run it and it would work. But with wash, we can actually compose these at runtime. So instead of wac-ing them together, we can run them separately, but in the same workload, and wash's workload resolution will automatically allow this service to call the component. So this is the entire workload that I'm starting — I don't need to mess with volumes or host interfaces or any annotations, really. I just basically run the cron service — this WASI CLI component as a service — and then I run one component, which is the cron component. So if I run this test — that captures all the standard out so I can make sure it works, and we can do it with an integration test — it runs, and then every second calls the cron component through that custom interface, and you can see the printout on standard error: "hello from the cron component." We get that four times because I run the service, and then I wait for five seconds, and then I tear everything down.
Brooks Townsend 48:00
But what's so cool about this is that this is a long-running component targeting WASI CLI, running in wasmCloud — or running with wash. I think this is effectively the beginning of our ability to proof-of-concept things like capability providers and extending custom functionality within the wasmCloud runtime. There are a couple of interesting things we have planned to support with this, like allowing a service to run and open up sockets, and then having the components in a workload be able to reuse those sockets — because it's already open, the long-running component can hold onto the socket or the connection pool, and then the reactive components, when they get an HTTP request that comes in, can just directly use that socket. These are some of the things we want to try and prove out with the service concept.
So this just landed in main in the wash repository — it's the ability to put a service in a workload, and that's just any component that targets the WASI CLI world, which should be many binaries that you can compile from Rust, or TinyGo, or even C — anything that compiles to a regular binary that you just run. I think there's probably room for a more compelling example in the service area, but it's really neat to see this working. I hope to work on some of the socket support next, because I think that'll cover some pretty interesting use cases, like replacing some of our more simple providers with components. Let's see, I see some stuff in the chat. Corey, lol. Yeah, exactly — this would be a great way. Or Ian asked: would it support an MCP server behind the standard-IO transport, which is done with WASI CLI? Exactly — if you're targeting WASI CLI, you could run your MCP server as a service. I don't think we pipe standard in / standard out to the component now, but still, there are some more things to figure out there. Frank, you had a question — how to make sure this is always live, like how to make sure that service just continues to run?
Frank Schaffa 49:49
Yeah, no, that's exactly it. I mean, if we're going to put a service there, we want to show that we have at least one replica or something that actually can respond, that the service is up and running.
Brooks Townsend 50:04
Yeah. So the service is a key component of a workload. You can define the maximum number of times that you want it to restart, but as long as the workload is running — which just means you started it — the service will execute for the entire lifetime of the workload. So if there's an issue, like you have an error and exit with a non-zero exit code, we'll restart that component up to the number of times you specify. But if the component exits too many times, or you don't allow for a restart, then the workload will transition to an error state — we'll actually report that in the runtime. We'll say, "hey, this workload failed, it couldn't run properly." Same thing for when you start the service initially: if you couldn't open up a socket to some remote endpoint, then we'll actually send you back a response that it failed to start. So I know that on the wasmCloud operator side, we'll have some integrations for you to be able to see in your Kubernetes dashboards that the service is still running, because the workload status is still healthy. That would be the best way to take action to make sure that it's always live. Does that make sense, Frank? Did I answer your question?
Frank Schaffa 51:42
Yes, thank you. Cool.
Brooks Townsend 51:47
Yeah. I mean — is service supposed to be the future of capability providers? I think, in terms of long-running processes that the wasmCloud host can start, it is absolutely what we want it to be. Now, I'm not saying that the abstraction is perfect, or that we won't need to change things, but I think, especially with WASI P3 adding improvements for streaming and just generally nicer interfaces across the board, and WASI TLS coming in, it's a really strong case for services to start replacing certain capability providers. Like, if you just have a couple components that need to proxy some messages to NATS, I think it's very doable to have a service that opens up a TCP socket to your NATS server, or over TLS, and then forwards WASI messaging messages on to the NATS bus. That feels completely doable, something a component should be able to do. And as a higher-level note for the folks tuning in — this is a stance that maybe I've taken, so I hope people agree with me — I don't really want wasmCloud to be in the business of running regular processes. I would rather focus entirely on running WebAssembly. So I hope that we can start just running Wasm with services in the workload API, and then if there's anything that still needs to be a provider for whatever reason, that's orchestrated separately, but next to the wasmCloud host.
Frank Schaffa 53:47
I was thinking, for instance, from the point of view of having OpenTelemetry that actually captures those things and sends them out as a service, right?
Brooks Townsend 54:01
That sounds great. So all the components wouldn't have to worry about exporting their metrics or logs or traces — they could just open a connection, I guess locally, to the service and say, "hey, here's all the stuff, you make sure it gets to the right place," and then that service is able to hold onto the connection to the actual collector URL. Unless we're already doing it automatically for you in wasmCloud, which I guess could be possible. But that sounds like a great use case for it. It's kind of like a sidecar — I mean, that's kind of what this service is, basically a sidecar alongside the workload. And ossfellow, just to answer your other question: will there be a so-called provider SDK? I hope not. I would prefer if we didn't have it, only because my hope is that we could just run any generic thing that targets WASI CLI, and we don't have special concepts that necessitate a provider SDK. I hope to drive basically all the service implementation and communication bits via WIT. So maybe we'll have a special WIT interface for advanced functionality — to introspect or ask questions about the wasmCloud runtime or something — but honestly, I would prefer that we didn't have it if at all possible.
ossfellow 55:56
Like, the host doesn't want to — or on the other side, the service wouldn't require some information from the host, let's say, to instantiate. I mean, give you an example: today we say that these are the components that are clients of this capability provider, right? So we kind of declare that. Are we saying that, as long as they just implement the required WIT, they can communicate with the service — we're not being restrictive in terms of what is happening between a client and a provider?
Brooks Townsend 57:01
Yeah, that's right. And it does change the relationship a little bit, like you said. Now, providers basically get told, "you have these five components that you're linked to, and this is the information you need to call them." But with a service, I think it would be much more one-to-one — one service is calling one component, or specifically calling one component over a WIT interface. Because if you have five components that need the same service, you could run five workloads, or run a copy of that service for each component, and it's much more lightweight than running a process. Which is one of the reasons why providers need to be able to be multi-tenant — because running a binary per component just starts to kill the value prop. We might need some additional runtime information in the service area; I'm not 100% sure, but yeah.
ossfellow 58:24
So, something I'm kind of thinking — let's make it out loud — is that the service needs to call back, right, especially if it's a long-running one. And for that callback, it could be part of the service WIT, and the components that wish to use that service maybe need to implement that, so the service knows how to get back to them.
Brooks Townsend 59:02
Yeah, I think that would be a decent way — and when I say decent, I'm not saying it's bad — having additional exports that are optional would be a good way to make that service API more powerful, without requiring you to implement anything if you just wanted to do the core, like the cron or the connector pattern. I think that'd be a nice way to do it, if we need it. I definitely want to hold the bar high that we should just be able to work directly with WASI CLI and WASI HTTP components, without anything special. And we definitely have that now, which is good.
ossfellow 59:59
That would be wonderful. Or rather — I assume that when you're saying that, you're referring to a transport, because again, NATS could be another one, right?
Brooks Townsend 1:00:25
Yeah, yeah. All right. Well, hey, we ran right up to the time with that — one demo only, wasmCloud Wednesday. So services are still pretty new. This is something we've been playing with for quite a while — how we might want to support long-running components. And starting with WASI CLI seems like a great place. So I'm going to be working a little bit on some more compelling examples of this. Workloads also support WASI filesystem and most of the WASI CLI world — not quite WASI sockets — but in the concept of a workload, there are some pretty interesting things we can start to do when we think about mounting the same virtual filesystem between a service and a component, and having socket-based communication over localhost, or maybe even in-process. There's some interesting stuff to tease out. Filesystem stuff would be cool for MCP too — and, oh God, well, I'm going to say this at risk of rabbit-holing right at the end of the call, sorry — same with Claude skills, being able to access the local filesystem or not, and that stuff is all really interesting. Okay, I said the cool thing, and then hopefully nerd-sniped some people, and then we're just going to leave. So thank you again, Ian and Corey, for coming on and demoing today — it was really awesome. Looking forward to seeing where the project ends up going as you guys make progress. Please feel free to let us know — you're welcome to come back and demo progress, like if you get it working on JCO or what have you. All fun stuff.
Corey 1:02:21
Thank you. I appreciate it.
Brooks Townsend 1:02:23
All right, folks, have a great rest of your wasmCloud Wednesday, and we'll see you next week.