Transcript: Q2 2025 Roadmap: WebAssembly on Kubernetes, HTTP & WASI P3
wasmCloud Weekly Community Call — Wed, Apr 23, 2025 · 66 minutes
Speakers: Brooks Townsend, Lucas Fontes, Colin Murphy, Eric
Transcript
Brooks Townsend 05:02
Hello, everyone. Welcome to wasmCloud Wednesday for Wednesday, April 23. Today for the community meeting, we actually have only one item on our agenda, no demo. It is community quarterly roadmapping planning time, which should be a fun one. Thank you all for coming on the Zoom, and I'm going to try to keep an eye on the live stream as well so we can make sure that we get all the feedback addressed here. So we did put up a discussion right after the last quarterly roadmapping planning on GitHub, and I didn't see anything really worth mentioning there in terms of feedback and features that have come in. So I think a lot of the valuable things that we have to look forward to over the next couple of months are pretty well outlined in our issues and pull requests that are open.
So we'll get into planning here in just a moment. I think I'd like to just take a little bit of a look back on the previous roadmap for the first couple minutes of the call to talk about how it went and what we planned and what we got done. So let me go ahead and share my screen.
Brooks Townsend 05:30
Looking back at the quarter one roadmap — just a reminder, if anybody's tuning in maybe for the first time or watching this, wasmCloud has been doing quarterly roadmapping planning for the last, wow, more than a year now. And really the whole goal is for us to get together on the community call, do kind of a special edition, and talk about what's important, what's coming up, and create a nice place for all the people who are working on this project to get their features in and highlight the good things we're starting on in big quarterly goals.
So taking a look at the goals for our previous roadmapping plan, which was for the first quarter of this year, we really wanted to apply some rigor to some of our APIs, our capability provider SDKs, and our documentation. A very large effort in the Wasm community space is dedicated to WASI P3, which introduces a number of things into the server-side WebAssembly space. So we needed to be tracking that and contributing wherever possible, and then continue to bring forward some of our previous goals from wasmCloud — like we should be the best developer experience for building, testing and deploying WebAssembly applications, and we should be enabling developers to build features without vendor lock-in, platform-specific dependencies or language constraints, all that good stuff.
After we were accepted as an incubating project in the CNCF, we essentially formalized this process. So if you're curious on how we actually do these sessions, we have a wasmCloud roadmap process in the GitHub. Look at us doing all of the organizational things.
So really, just a quick look back through the issues and things that we committed to: I think we knew that this was a pretty ambitious roadmap with the amount of items that we took on. We added a couple features during the roadmapping planning call that weren't very fleshed out, and so I think you can see that reflected here — something like external capability provider support, something we know that we want to work on, but we didn't really have an RFC for at the time. That's a really difficult one to pick up as a contributor or maintainer.
There's really not too much that we didn't get started on in the quarter one roadmap. When it comes to correcting inconsistencies or defining our cloud events in a language-agnostic structure, I think these can move forward onto the quarter two roadmap as carry-over things. You'll see we have quite a couple of issues in the In Progress column here. So Adi has put in some awesome work on the cron job capability provider that's actually sitting in a PR now. Same thing with the NATS object stores, and OSS Fellows' built-in HTTP client provider — there's actually a pull request open for that. Same with using clap autocomplete. So these are things that actually are moving forward just fine, and either need a little bit more reviews or to just get pushed across the line.
I think on GitHub projects, we can tag issues and pull requests as being part of a roadmap. And going forward, what I'd suggest — and anybody's welcome to offer feedback — is for these remaining issues, the cron job provider, the built-in HTTP client, clap autocomplete, we can bring these forward in terms of their open pull requests. So we can tag the pull request on the roadmap, and then that's the thing that we need to be reviewing. And once it merges, then that item is complete. Previously we just didn't put pull requests on the roadmap, but I think it makes sense for things where the pull request has been open for a minute and that is the remaining piece of work. The goal is transparency and showing where we're putting the effort.
Brooks Townsend 12:43
As far as WASI P3 — definitely in progress, and a huge thanks to all of the folks on the wasmCloud side who have been dedicating their time, or at least part of their time, to WASI P3. I know that Bailey, as TSC director, is putting in a ton of time to drive this across the line; Roman, who has been contributing to WASI for a long, long time, is implementing WASI P3 inside of Wasmtime, along with other folks in the Bytecode Alliance; and Victor Adossi has been working both on the JavaScript tooling and on the Node runtime piece for WASI P3. So we have been doing a pretty fantastic job of putting resources towards it. This serves as a nice marker on the roadmap, but there isn't really anything actionable — it's just tracking for wasmCloud. I've made good strides in bundling wasmCloud and wash, so I'm hoping to wrap that up pretty soon with some of the things that I've shown in the community call.
So we did pretty well. We tackled some big refactors — thank you, Ned, for coming in and taking time out of your schedule to consolidate the wash CLI and wash lib. This has been awesome. It's so nice to just contribute something to wash and then immediately get it out and not worry about, does this need to go in the library or CLI.
Now, the wasmCloud dev stats is something the CNCF provides to us. It gives us all kinds of statistics on what we've been doing. So if you look at the last quarter, you can see the dotted lines vertically are when we've done releases. We've been keeping a nice monthly cadence for wasmCloud releases. Our contributors naturally took a dip in the sad times of the year and are coming back up. If you take the average, we have an average of 30 contributors on a month-to-month basis for wasmCloud, and we made over 3,500 contributions to wasmCloud just in the past quarter. That's commits, pull requests, issues opened. That's huge. We're approaching 2,000 stars on GitHub.
So when you take a step back and look at our roadmap: we completed nine items on the roadmap. But if we had 3,500 contributions and hundreds of pull requests closed, then we're definitely spending our time on wasmCloud — not necessarily a majority of the time on what we came up with during the roadmapping session. Lots of things come up after the roadmapping session. Any bug that gets filed for the next two months would not have been present here, but we'll still complete it.
So looking forward, I want to make sure that we capture open pull requests on the roadmap so that we can close those out and pad our stats, wink wink. And I want to make sure that the majority of the things that make it onto the roadmap come from open issues that have been triaged by maintainers and put in the right place, more so than the larger, more open-ended issues that we've committed to on previous roadmaps. I'll take an example: revisiting the provider SDKs, provider testing ability. This is fairly vague. It doesn't really give too much instruction about where to go. It's really just a long-time maintainer needs to go and triage this.
Brooks Townsend 18:20
Because of this, I have a couple of suggestions for the next roadmap. I've set up the quarter two 2025 view on the wasmCloud project, and I've changed the categories. I put them in a separate GitHub category, so it's not going to mess with anything from before, but I've set them up to be research, development, and good first issue.
Items in the research category should be things like WASI P3 — these are big, long-standing issues that WebAssembly experts are going to be working on, and they're more open-ended. They may result in RFCs, like Taylor's exploration into plugin-defining wash. Development items are another level of concrete beyond that — well-defined features, enhancements, things that have a clearer scope. Anyone who is familiar with the wasmCloud ecosystem should be able to take these. So I'll give an example: one of them is Blobstore S3 environment variables. When we run the provider, we actually scrub environment variables from that provider's environment, so we need to change it to use config and secrets instead. This is something that anybody familiar with the provider model could take and complete. It's intended for any maintainer, anyone who's contributed before.
And then the final category, which is another huge goal of mine: to provide a clear entry point for anybody who comes to wasmCloud and is like, this is cool, what should I work on, how can I contribute, and what's important? All of those items should go into good first issue. If anything comes out of this roadmap planning, I would love to have a place where people can come in — if you have any Rust knowledge at all, or are willing to ask an AI about it — this is a perfect place to get started.
So before we talk about some of the issues I've brought on here, do folks have comments, questions, concerns about the category change? Just a reminder, we're going from categorizing the issue by documentation, new feature, and improvement — which is helpful, but doesn't give you a clear idea of what you should take — to research, development, and good first issue. Sorry, I talked a lot, but does anybody have any thoughts, comments, concerns about that one? Yeah, Lucas.
Lucas Fontes 20:52
This is kind of related to the task that you showed that was in the good first issue — it was like "something is not working, needs to be better" kind of thing. I think items that go into the roadmap should be specific. We know what needs to be done, therefore it's going into the roadmap. If something is a bit ambiguous, it goes into research, because research is not only for looking into new things, but also for investigating why a specific bug is happening. It's mainly to ask here if that specific task should actually be moved to research, because it seems like it was valid, but also not in the right category.
I'm pretty much talking about the one that was in Q1 2025 — revisit wasmCloud provider SDK testing ability. I think the point is this is an improvement, yes, but it's also not specific. It's not telling us what needs to change. We know there are deficiencies, and somebody needs to come up with a list that will then have the right priorities.
Brooks Townsend 23:09
Yeah, 100%. I'm happy that you arrived at this conclusion, because this is exactly what I wanted from the research category. Anyone could take a look into the provider SDK, but to really dictate the vision of where it's going, it would be best to be someone who's written a couple of capability providers, somebody who's worked on the SDK. Like you said, it doesn't have a clear end goal or scope for completion, so it would go in research and then likely result in either a couple of issues or maybe even just a pull request that says, here's my proposal for how it should be fixed.
Lucas Fontes 24:13
I also think if we start looking at the issues that we have right now, there's an opportunity. Sometimes we have issues that would require specific knowledge. So we need somebody that has worked a lot with the WASI HTTP bindings, and that work — either there's a bug and everything is burning and we need to go fix it right away, or it's one of those bugs that happens once in a blue moon, not affecting a lot of people, so it flies under the radar, but is impacting service for a few, and the impact is severe for them.
So I think a few things get to a point where it's death by a thousand cuts. And HTTP might be a good example here — we start seeing so many little issues in HTTP that it warrants bundling that work together and creating some focus, some mini task force around HTTP as a theme. That way we have enough work that somebody who is going to have to do refactors can consider all those issues when doing the refactor, but they can also pair with someone in that effort and ramp up someone else in the process, and have someone else also understand that codebase and be a bit more familiar with that section. So I think where we should wrap up is to say: let's not look at bugs as individual bugs, but more as categories — and these categories, despite the research roadmap, are the area of the code. This is going to be inside lattice, inside the wasmCloud host crate, inside the tracing crate. And this way we can pair experts with people that are also willing to participate.
Brooks Townsend 26:55
Yeah, a bundle of great ideas there. You called out that if you look at the open bugs, there are a couple of similar bugs around the experience of HTTP, which touches many, many different things. So there's a general theme that we need a little hardening around that experience. And when you think of general hardening, that may be something best accomplished by a maintainer, somebody familiar with where the HTTP inner workings are coming from, and it's a good opportunity to bring people in who are interested in contributing or who are already maintainers.
I'll pick on you, Mark, because you're here. Say you're a TypeScript maintainer in wasmCloud, and you noticed a TypeScript bug, but aren't really sure where that's coming from in the wasmCloud host. You and I, or you and Roman, or you and Lucas could hop on a call and figure that out and fix it on both ends, and it just makes everybody better for it. So there are many different categories we could tag — we could add more roadmap categories for where it exists in the codebase and what the area is. But Lucas, I think what we called out is we need, on this current roadmap, in the research category, a broader issue around HTTP.
Lucas Fontes 29:27
I think this is the perfect example for an item that should go into research. It's really not specific, so it's everything HTTP. Look at the settings that we do for the HTTP provider and see if they are consistent. Why do we have default address with a dash and default address with an underscore somewhere else? So it's a full pass around HTTP.
Brooks Townsend 30:09
I'm just going to free-hand some of this, so please feel free to correct my writing. As discussed in the roadmapping planning for Q2 2025, there are quite a few issues in our backlog that pertain to HTTP. We should broadly harden our HTTP support across the wasmCloud ecosystem, and ensure we are consistent, failure-resistant, and easy to use.
Lucas Fontes 31:06
And I suggest a goal for this one — a goal like an overarching what good looks like at the end here. Is it when we feel comfortable taking the built-in HTTP provider out of experimental?
Brooks Townsend 31:47
Stability structure, and can commit the built-in HTTP provider to the SemVer strategy we apply to the rest of wasmCloud's features. Does that sound reasonable? I really like that concrete goal. We mark things as experimental because we want to have the freedom to change them, and to say, hey, you're opting into a new thing here. We have a lot more flexibility with the external providers to change them, but in the host we need to feel solid about it. See the April 23 community roadmap session for more details.
We also need maintainers. Examining the HTTP strategy fully requires looking at wasmCloud guest SDKs, the Virgo and Rust wasmCloud host, the HTTP implementation, and the host built-in HTTP server and client.
Lucas Fontes 33:37
And probably a little detour into WASI P3, and preparing the wasmCloud codebase to receive WASI P3.
Brooks Townsend 34:04
Yeah, that sounds good. Quite honestly, there is something that goes even beyond just wasmCloud itself here too, which is: what is wasmCloud responsible for on HTTP — load balancing, routing? When would you just use wasmCloud, and when would you front wasmCloud HTTP endpoints with a reverse proxy or an ingress? How does it integrate with Kubernetes or Envoy or Istio or any of those things?
For those of you who've been keeping an eye on what we do for HTTP for quite a long time: making an HTTP request is the easy part, but for listening on HTTP, we reserve a specific address and port, and now we have routing modes where you can route based on path or based on a host header. The host header works just like you would expect in any proxy, but for path, we're not supporting wildcards or variables, and adding a lot of that stuff is a decent maintenance burden for us. As a project maintainer just trying to be the best WebAssembly platform, we don't need to build an ingress too. So I'll put it under alternatives, but I would love to see a broader documentation stance that we take as wasmCloud HTTP developers, on how it should integrate with existing tools like Kubernetes, Envoy, Istio, and NGINX.
I don't want to expand the list too much, but I think if we constrain ourselves a little bit to say wasmCloud is responsible for getting the HTTP request to the component, then it helps us with scope in terms of routing modes we need to suggest. A big item on the last roadmap was actually — Colin, can you refresh me a little bit on that one? It was around Envoy.
Colin Murphy 36:49
Exactly what you're saying. My own journey with it ended when I started talking with Luke, because he was like, we're doing whole new CRDs. It sounds like you're going to have something like a Kubernetes API server no matter what — essentially, in production use cases we'll have a Kubernetes API server, and we'll use a Kubernetes API server. That's kind of the answer for this thing. Your question was, how is this going to work? Well, we're going to have a Kubernetes API server, and then solutions for Kubernetes-based things like service meshes and Envoy and stuff like that, which are built to work within the Kubernetes API, will come from there.
Lucas Fontes 37:56
I also think the challenge here is when we're looking at load balancers — load balancer targeting, you need a stable port in most environments. You go to AWS, the load balancers will expect a stable port. You go to GKE, same story. And the fact that we can bind providers to any port adds some complications to the mix, specifically for the Kubernetes case. What this means is it's very unlikely that we can use regular Kubernetes services for load balancing, because Kubernetes services need the port to be configured. What you have to use instead is a service type external name, or headless, which provides you just Kubernetes DNS pointing to pods — so then you're not doing load balancing anymore, you're doing DNS load balancing.
So a lot of what should go in here is explaining when to use which type of provider. Do you want your HTTP components to never be able to share — to have impersonation, for example, because you don't process the host header? In that case you want a dedicated capability provider. But if you are in a multi-tenant environment that has 500 different components, you don't want to assign one individual port for every one of them. Then you need to go to a single HTTP provider, but you also have to make sure that the host name is correct. There's no simple answer; it depends on the use case. And I think explaining when to use each provider for each use case is what we're missing here.
Colin Murphy 40:17
It sounds like we're also just missing how that would work. We need to flesh out those two use cases. We can identify two scenarios, and then we have to identify what it actually looks like if you're in one scenario or another — exactly how that all gets set up. There are obviously going to be trade-offs there, and it might get super complicated and not even work if you go down one route.
Brooks Townsend 40:52
Really, our goal from the wasmCloud HTTP side should just be to give you the tools to get an HTTP request to the right component as efficiently as possible. So if we can implement host-based routing — basically DNS load balancing to a specific component — and that is enough for you to configure your NGINX, Envoy, whatever, to get to the right component, that feels like what we need to do, and not much more. It should be brain-dead simple for the local dev use case — hit 8080 — but then once you go to production, just being able to do the routing properly seems super important.
Colin Murphy 41:42
You should be able to stand up a kind server as well locally. You don't have to, but you should be able to have that and be like, oh, this makes sense, this is how this works, and then I can have the confidence to replicate this somewhere small.
Brooks Townsend 42:02
Definitely. Amazing. So now on our quarter two roadmap is more of a deep design exploration of HTTP in the research category, and there are a couple of good first issues and development things that will spin out of that that are already filed.
As I mentioned earlier in the call, I've been pruning through our previous issues for things to come onto this roadmap. I want to make sure that as we accomplish roadmap items, we're also knocking down issues that have been open. So there's a couple more to go through here on my end. We have about 20 minutes left in the regular call. We usually roll over on this one anyways, but I just wanted to open the floor at this point. Do folks have issues that are in the backlog, or even pull requests that are open, that we feel we should prioritize for the next quarter? Keeping in mind that we're doing this a little bit late, so looking through the end of June for this one — what else should we make sure that we capture on this quarter two roadmap?
Colin Murphy 43:45
I'm sorry, because I came late — can you just show what we already have on there?
Brooks Townsend 43:52
Yeah. And I know, Colin, you're going to be a good researcher and go back and watch the whole video before or after. But essentially, for this current roadmap, we've moved some of the categories to who can take them and their scope. Research is more big design work and things like WASI P3 tracking; development, any maintainer should be able to take, they're well-scoped features; and then good first issues are even smaller scope, things that anybody should be able to take. So on here, other than rolling things over from the quarter one roadmap, we've brought in things under triage like a host configuration file — just having a single file you can pass to the wasmCloud host and it configures everything, no need for a flag.
Colin Murphy 44:52
Sorry, Brooks, don't go over everything just for my sake. But I would say there's probably — other than HTTP — there needs to be at least some sort of validation of all the 0.3 features. I would say make it like an epic.
Brooks Townsend 45:19
Yeah, for sure. This one definitely goes in the research category, but there isn't a ton that's takeable right now, other than examples.
Colin Murphy 45:36
Examples, really. Providers.
Brooks Townsend 45:45
Yeah, some of the most important stuff is just keeping an eye on the different interfaces — how they need to change, like HTTP changes in WASI P3 — and how providers are going to change, all that stuff.
Colin Murphy 46:01
All right. So if I'm not adding anything, is that what I'm getting — everybody's already fully thought that through?
Brooks Townsend 46:09
We didn't talk about it all in this session, so I think it's really important. It'll roll forward from Q1, but it's incredibly important for the future of wasmCloud. It's feasible that WASI P3 wouldn't be a breaking change for people who have existing components — we can still support WASI P2 just fine — but rolling forward and adding support for P3, there's potentially a lot there, so we want the best ability to mitigate that.
Colin Murphy 46:46
And at some point, having 0.3, you'd have to have wadm or your Go SDK probably updating.
Brooks Townsend 47:36
Let's see — Lucas said, have we documented the behavior of the bus error type? This is the new one, right? Maybe, I think we started on it. I think it might still be something we need to do, so let me just go and file it, and if I'm wrong, then we'll just close it later.
For folks who didn't see the PR come across: this error interface essentially propagates a type from wRPC, but it allows you to do error handling for custom interfaces that you do for wasmCloud. So if something happens at the transport layer — like your NATS is disconnected, or your TCP socket is not bound — we can actually return an error to you in the Wasm guest. It doesn't panic. So it's incredibly important for doing error handling with custom interfaces. Let me file that as a documentation item.
Eric 48:32
Brooks, we have started that, but it's not in a PR yet. So you've seen an early version of it. That's why you're thinking, I know I've seen it somewhere.
Brooks Townsend 48:42
Okay, amazing. Eric, while you're here, would you mind just filing an issue for that in the wasmcloud.com repo? Amazing. And then you should be able to add it to the wasmCloud roadmap project, and you can just slap that into quarter two under development — I think that's a good place for it.
Let's see — Florian, you mentioned the workload identity RFC. So Jonas and Colin have been working on this one for a little while. This was originally proposed about midway through last quarter, so it didn't make it onto the last roadmap because it was proposed in February. But it is incredibly important. Jonas has landed a couple of features in wasmCloud for workload identity — we've at least seen a POC of connecting to NATS with workload identity, and the ability for an individual component to fetch its workload identity, and that was essentially what Colin and Jonas demoed during KubeCon.
I do want to move forward workload identity, because I think it has a lot of potential to be an identity verification mechanism that we just don't quite have today. We have decentralized auth within keys, but there is a pretty big issue upstream in SPIFFE right now, which may affect how we implement this for components. So I'd love to move this onto the roadmap, but it's possible what we have proposed is going to change based on the output of this issue. This is the support for sidecarless service meshes, specifically Istio ambient mode. This is basically the mode that we run the wasmCloud lattice in — NATS is not required to be a sidecar, and the lattice is this flattened topology network that is everywhere. So if this affects the way someone would configure workload identity and deploy it in an Istio ambient mesh, then it would likely affect the way we would want to do it in wasmCloud.
Colin Murphy 52:32
Isn't this basically taking a SPIRE feature and bringing it into SPIFFE?
Brooks Townsend 52:38
Potentially. I'm actually not familiar with that, so it might be.
Colin Murphy 52:44
So it changes how, if you are using Istio — I did look at this, I've done many things since. If you use Istio for SPIFFE, and our Istio integration story, if you were actually managing the relationships between services using Istio, then our story could change. We could not require people to have their own SPIRE server. We could say, yeah, we can use Istio too — we'll have workloads, and Istio will know what they are, and you could manage connections between things, especially Kubernetes stuff and wasmCloud stuff, using Istio. It would be a little bit more configuration too, because you'd probably have to configure it so that Istio just doesn't care if wasmCloud talks among itself. I don't know, this is where it's going to get a little tricky.
Brooks Townsend 54:07
Yeah. Okay, then in the vein of our new fun categories, I would say we just throw it under research. This is something that Lucas, Colin, Jonas — when you watch this — I'm looking maybe a little bit more to you guys, not to feel like you have to drive this across the line in the next two months, but really to set the future of the identity story, because I think it's really important. We should also probably talk about it, because wasmCloud has a concept of identity now, sort of — not for a running workload, but more for a build artifact based on an embedded JWT. So all I'm really saying is that we've made attempts at this before and done it somewhat, but probably have an opportunity for going deeper, just doing a bunch of SPIFFE stuff — and for providers, yeah.
Colin Murphy 55:24
It should just work. You shouldn't even have to know.
Brooks Townsend 55:28
You should not even have to know, yep. I think we determined it should be optional too. Just like Istio, just like Kubernetes — wasmCloud should be able to work with it, great, but you shouldn't need it. Okay. Oh wait, there was one more issue — Colin, WASI WebGPU.
Colin Murphy 55:56
I just added that in because I might do a KubeCon talk about it. I feel like once we've got the WASI WebGPU thing landed, we're going to want some examples. I don't know if that needs to go on the roadmap, it's just something I thought of. But everybody wants to run machine learning stuff, right?
Brooks Townsend 56:21
Wasmify your LLM. I don't see any problems with that. I'm super interested too. I thought that WebGPU is legit — it's working, people are experimenting with it.
Colin Murphy 56:43
I don't think it's landed. When I last talked to Sean, WASI WebGPU headless is not in Wasmtime right now yet, at least as of April 10.
Brooks Townsend 57:09
Okay, I swear Bailey mentioned something about this being worked on.
Colin Murphy 57:17
It's getting worked on.
Brooks Townsend 57:20
Okay. I'd be happy to throw this on, I just don't really know it well enough.
Colin Murphy 57:26
Don't, don't. It's just something I thought of. I felt a lot of pressure, put on the spot.
Brooks Townsend 57:36
Colin, have you contributed your 10 quarterly roadmap items that we need to work on, as is necessary by every contributor? No? Okay, we'll keep an eye on WebGPU, because it is relevant. If we can have a story for bringing that in on Wasmtime to let you interact with the GPU, that'd be pretty cool. There's just not really a clear scope, which is what research is for.
So, I think we're pretty much at the end of the call today. Just to summarize, the current roadmap is almost complete. I'd like to finish going through some of the issues in our wasmCloud backlog and get them tagged appropriately. For the goals of Q2 2025, we should really be looking at preparing wasmCloud for WASI P3 and generally doing stabilization passes on some of our most common workflows. So, people using wash dev, trying to remove the binary download and run things embedded in wash; taking a look at the way we've had trouble extending wash in the past, and having folks be able to add custom functionality — bringing the plugin mechanism to the next level, which is why the plugin-in-wash item is on this roadmap. Easier configuration. And taking care of the deep design of HTTP. We know what the happy path is for most people's local development story, and what you hit as you try to take it to production. So taking a lot of the issues we have on the current list and pulling them up on the roadmap will be really nice, just to keep us accountable and knock some of those things out, so that we can focus on being the coolest, most awesome WebAssembly project out there.
Brooks Townsend 1:00:00
Oh, there is actually one more thing I'd like to propose to bring onto the roadmap. The one other thing I'd love to bring on — which was not my idea, but I did put up the RFC — we've been rolling with the ~/.wash directory for quite a while, and it's worked fairly well. We put files in there and then we read them later. But this isn't really adherent to any existing standard or convention. And there is one that covers what we want to do pretty well, which is the XDG Base Directory Specification. Maybe I'm the one who put in the create-the-.wash-directory; I just didn't really know that this was a thing. So thanks to whoever nerd-sniped me into this.
I think it would be great to respect this convention: put context and configuration in the XDG config home directory; downloads, developer logs, and keys go into the data home; and package cache and JetStream directory go into the cache home. If you've ever installed a tool and then in your home directory you notice under .config you get a directory — that's what this directory spec is like. Instead of creating another directory to populate the user's home, let's put it in the fairly expected place. We don't have to be so rigorous about this — we could just throw everything under .config — but while we're here, why not? This will also be important when we get to plugins. So I would love to do this one. It feels like an easy lift and something we should do. Anybody hate this? Anybody have a personal vendetta against the XDG thing? Okay — Lucas says thumbs up, Sudan Su is laughing at me, and Mark says party time. Good enough for me.
This one can go into the development phase. Honestly, anybody would be able to take this as a good first issue. I just put it in development to consider the implication of moving the directories and where we're putting binaries. So that was my last one.
Brooks Townsend 1:04:32
All right, do folks have anything else they'd like to propose to be on the roadmap? Awesome. Well, thank you all for coming today to your regularly scheduled quarterly roadmapping planning. I think we'll be a little bit more timely about the next one, because there isn't a big conference and then everybody lagging out after that for this one. So I'll put up a little draft of the conclusion from today's roadmap. I know there are quite a lot of issues that are going to be on this one, but they really are coming not from new work, but from existing issues that are filed. So I think this will be — what's the Apple way of saying this — the most focused roadmap yet. We think you're going to love it. And I think that's really it. Thanks everybody, thanks for being here, thanks for putting in your feedback and spending the time. Let's get to work. Have a wasmCloud day. See you next week.