 Okay, recording. And that is exciting. Hello, hello, hello. Everyone ready to talk about scope managers? Someone from Datadog put this up. And I'm sorry, I'm spacing on your real actual name. Rock? Rock. Rock. Nice to meet you. Nice to meet you too. Thank you so much for putting that summary together. I'm wondering if you mind moving this section of the winning. You've been pushing this issue and have a lot of good things to say on it. I'm sorry I missed that, there was a bit of noise. Oh, sorry, I was just, so the first part was discussing JavaScript scope managers. You did a pretty great write up and review. I was wondering, would you mind kicking off that section of this meeting by maybe just doing a summary since you've been pushing on this one? Okay, so I'll basically summarize our findings by implementing the first version of the scope manager in Datadog APM actually. So yeah, at first it was, I think in July, that we released the first version of the scope manager. What I did is I implemented it exactly according to the specification from open tracing. And while it's working, it's also led to a few problems. For example, it doesn't really work well with a single weight because the way the construct is built, it should be wrapped in a function to work efficiently. So by using the activate and close pattern that is described in the specification, it doesn't really work well with JavaScript. So that's one of the problems. Also, it requires an asynchronous context to work properly, which is another issue that we faced. I guess this issue was mostly because we were trying to keep track of the asynchronous context. But all children, so for example, if you schedule work, it would wait until all the work that you scheduled is finished to actually close the scope. So yeah, a few things there that did not work super efficiently. And then there was a PR and also an issue opened by Paul Draper. I don't know if he's here today, I don't think so. So it was basically a discussion about using continuation passing style instead of the imperative API from the specification. And from there, we had a few discussions and I think it really makes sense to have a continuation passing style for JavaScript. And then it led to basically exploring the options for such an API. And I think in the end, it deviates quite a bit from the spec. We're trying to keep the wording as much as possible. For example, where it's like scope and activate. But yeah, I think for JavaScript, we'll need to deviate quite a bit. I don't know if you take a look at the proposed API. But yeah, so that's basically what we're proposing right now. And there's also the issue that in JavaScript, there are tons of different runtimes. For example, different node versions that have different restrictions, different capabilities. Same for the browser, which is completely different than nodes and it has no construct at all for context propagation. So there are quite a few different libraries depending on the environment you're on to address context propagation. So the thing is for the scope manager to be compatible with node 0.10 plus and the browser, it needs to have multiple scope managers implemented basically for all these different runtimes. Right. So I guess this is the current state basically. Awesome, yeah. So to summary, there is a need for scope managers in JavaScript due to the various runtimes and environments your code might run in. So there is a need still for there to be an abstracted scope manager interface because you do want multiple implementations. And a new API that is more continuation based has been proposed. People have been poking at it and are generally happy with it. Would you say that's kind of where it's at? But perhaps it's not been exercised very thoroughly. It's like a theoretical API at this time. Yes and no. I mean, the API is very similar to existing libraries that deal with context propagation but from an application perspective. So arbitrary values that you want propagated. And they use a very similar API. And if you look at all of them, even though there are differences, it's basically the same functionalities that always come back. So things like, well, the continuation itself. So the ability to pass a callback and have a context in there. A few utilities for binding because sometimes you want to actually bind to a specific value from a different context, for example. And things like that. But so of course this is a theoretical API at this point. But it's based on existing work basically. Great. That's awesome. Thank you so much for that summary. I certainly have questions but I would love to open the floor up at this point because I know other people have been working on this problem and also probably have questions. So I'm going to step back now. I can open up and ask why you have looked at node versions going back all the way to 0.10 and not just version six, which is the oldest that is still actively maintained. Okay, the reasoning, well, for us specifically, we support node four and up. Meaning that in our case, we would need support for node four because actually one of the issue is we don't really control the version of node that the customer will use basically. Another reason is because open tracing itself like the current open tracing JavaScript library already supports 0.10 and up. And there was a few discussions in the last few years, I guess, to drop support for these 0.x but it's always been refused because I think some very, some large users of the library are still on 0.10. So this is basically the reasoning at this point for that. I would ask is, and it maybe is slightly parallel to this, but as a result of this, is there a thought that maybe we could going forward move the expectation of support level to be whatever the current LTS node releases are? Well, I mean, I think as long as we are still able to support older versions, it makes sense so that we don't block anybody. For example, if some company implements the open tracing JavaScript for the library, but they need to support 0.12, for example, it should be possible if it's, you know, not too much work to support. But the thing is, even older versions of node are not that difficult to support. Most of the work has already been done. Probably some of you might be familiar with the AsyncListener library, which handles pretty well all of the node API basically. And having a scope manager on top of it is not a lot of work. The biggest part of the work is really to split the current project in multiple libraries. So for example, to have each scope manager in different modules, basically, so that we don't just bundle everything even if it's not needed. And so that's pretty much the largest part of the work. And it has to be done anyway to have, at the very least, one scope manager for the browser and one scope manager for node. So at that point, the overhead of supporting older versions is not very high. Of course, it limits our ability to update a few libraries because the libraries that are used by OpenDressingJavascript might no longer support older versions of node. But so far, I don't see any blocker, basically, to keep the support. I can just chime in. So we in Elastic APM, we just released version two of the node agent in which we dropped support for node four. So now we only support six and up. And the reason why we dropped support for node four was because it started to become increasingly hard to maintain that support because, of course, we wanna run our test suite on all the versions we support. And as you say, new versions of modules were released that either without bumping major they dropped support for an old version of node and suddenly they started failing. Or they weren't maintaining one of those old versions and might have security issues. So we felt it was not safe to keep supporting that old version for those reasons. But by the way, I can see that you made up a fork of AsyncListener. I'm actually a maintainer of AsyncListener. So yeah, if you have any questions related to that, let me know. And I mean, I would just add to that that I'm bringing this up because of LightStep were considering removing support for node versions prior to six as well in our client library. So for very similar reasons to what Thomas said security issues with older dependencies and so on and so forth. Yeah, I mean, of course, it's always something to consider. We also considered that problem being we still have quite a few customers on node four. Of course, they are slowly migrating to newer versions. But yeah, I mean, it's also related to the dependencies. I guess and Open Trace and JavaScript doesn't really have a lot of dependencies. Well, it doesn't have any dependencies right now, meaning there are basically two parts to this in my opinion. So there's the tooling, so that I like to build, to test and that kind of things where you might want a specific node support and there's the actual output. So what you're gonna ship, which in this case has no dependency, meaning I think it would be possible to update the tooling and say, okay, to develop in the library, you would need, for example, node six and up, but then still make sure that the output would support older version. Of course, this might be difficult if your tester doesn't support it, but I don't know, I'm just playing kind of devil's advocate here. But yeah, it would be something to consider for sure, but I think this is a discussion on its own, basically node support, because it can have a lot of impact. And also wanted to respond to Thomas about the AsyncListener fork. Right now it's not used anywhere. I just forked it to try and make it consistent with the other libraries. I understand that AsyncListener is basically the first one, but all future work use a different way to bind promises, which are always bound when then is called and not when resolve is called, which is a major difference from AsyncListener, which binds on resolve. So to have a consistent behavior between all the implementation of a scope manager, they need to behave the same for promises. So what I did is simply remove all the logic related to the promise and bind on then instead. And the idea was really to have a consistent behavior. This is not a problem with, for example, any CLS, like Consumption Local Storage itself, or CLS Hooked and other implementations of the sort, because you're usually using only one anyway. So if in your app you have node eight, you're using Async Hooks and you don't need to know about AsyncListener and so on, but if you want to have a common project, like a scope manager or something of the sort, then it becomes very important that the scope is propagated exactly the same in all implementation. And this is true for also zone.js, which binds on then, node domains, which binds on then. So pretty much the whole landscape at this point binds on then, but I guess for a historical reason, it's not the case with AsyncListener, basically. We have had the discussion in the AsyncListener before, sorry. Right now I can't remember exactly why we are still binding on resolve and not then, but I guess it should be possible to make a new version. We could even just bump the major of it, that changes that behavior. If I don't, you have your call correctly, I think that should be possible. Yes, I've seen discussions as well about actually releasing a 1.0, now that it's been stable for a long time. So I think maybe the 1.0 could bind on resolve because this is the current behavior. And then maybe we could work on like a 2.0 to make that change, basically. I like it. Oh, I have a, I'm sorry, go ahead, Austin. Sorry, I guess to get back on to the topic a little bit. I know you were talking about read, I believe my interpretation of what we were talking about in Gitter is that you're rewriting the library in JavaScript and then supplying typings rather than having it written in TypeScript. Is that accurate? Or is that just actually accurate? Yes, I'm still exploring the options because I guess there's, I don't know, like that people wants the library to be TypeScript, so I'll try to get it to stay in TypeScript. But the core library won't change, that's for sure. But I mean, because the scope manager itself, the problem is that there are a few newer constructs like generators in Async Awaits, which are not available in the current target version of ECMAScript, so meaning that even if you write tests for Async Awaits, they will end up as promises or callbacks or whatever works best for the target. So you're not actually testing Async Await at this point. And since this is implemented in C++, it's not really possible to replicate exactly how it works in JavaScript anyway, so it will just convert it to a regular promise. In the real world, it's fine. It will work exactly like Async Await. But when you're instrumenting, it's a bit different, because now you need to really handle this specific case and you need it to not be transpiled, basically. So this is, but I'm still exploring. I'm still trying to get it to work and keep it as TypeScript. What I think I'll do is use a different target when testing, basically. So I won't pre-compile to JavaScript. I will just load it directly with TSNode or something like that so that it's compiled in memory. And then use a different target and just say like ESNex or something like that, like to make the transpilation as lightweight as possible. So yeah, that's the plan right now and we'll see how this goes. Awesome. Thanks. Is there a fork or a branch where this work is going on that I can see? Actually, I started this work this week. It's not, I haven't pushed anything yet. The reason being that I'm kind of realizing that this is a bit of a kind of worms, because now that I'm also splitting the library, I need to have Lerna working with different libraries, the code coverage right now is being a bit of an issue. So yeah, I'm actually open to suggestions about how to go about, let's say, a first push. Should I just maybe not go with the split right away or should I just do the split and not the scope manager? I mean, I'm just trying to basically figure out the minimum that I can do that I can actually push and it works basically because right now it's not really working. So even if I push it, like everything's gonna just fail and which I could do as well if you want to take a look. But yeah, I'm open to suggestions here. It's fine. If you need more time to figure out how it's best, then that's fine. I was just thinking like if you wanted a feedback, it would be easier if it was, I don't know, maybe I'm not sure if it's possible to do in a PR or in a separate fork or something like that. Of course, you shouldn't push it to necessarily master. But yeah, it was just to see if I could give any feedback at this point, then it would be easier. But if you wanna stay around with the first a little bit more, then that's fine. Yeah, my plan was actually to either make a PR or at least push something next week, probably by the middle of the week if possible. And then we can discuss anything that is from the points that we mentioned. And yeah, so that's the plan. I will try to push something the next few days basically. Great. Yeah, I would love to see this as a release candidate branch on the repo that people could start consuming. It seems like we're close enough to an API that the next step is binding to it and kind of putting the API through its paces. I had a couple of questions on that front. One was just to circle back to node version support and just to clarify, is there anything about, besides just tooling, independency management, is there anything about the API being proposed that people would change if we changed what kind of node support we were looking at? Or is this purely a tooling question? In other words, we're not reaching for something in later versions of JavaScript that we would want to be part of the interface, but we're avoiding because we're looking for backwards compatibility right now. Not that I know of, I think, and I'm not sure about this because it's been supported for a long time, but I think one of the reasons maybe that everything is a function, as opposed to getters in some cases, is because it may have not been supported in those versions, but I'm not 100% sure. But other than that, in at least my point of view, I think the API would be exactly the same and then you were an old version. Great, thanks for clarifying. I had some questions just about the API itself. In particular, I was curious about the usage of being able to access the scope's parent scope and root scope. That's probably the biggest change I noticed from a functionality standpoint compared to other scope managers. And I was curious about the attention behind exposing the scope chain in that manner. Yes, this actually added this morning, I think. I guess I was basically to discuss it. So I really don't have a clear idea of how this would work, but the idea is that in some cases, you may want to enrich maybe the parent or in our case, what happens a lot more often is to enrich the root. And right now, there's no way to get the root, basically. So I'm more concerned about the roots than the parent, to be honest. And in most of our tracers, we started to basically add this concept of root. I think it's called something like active root span or something like that, which is a property that we're slowly adding to the tracers. The problem for me is that I'm trying to keep the JavaScript implementation as 100% open tracing, meaning if possible, and so far it's been possible, I don't add anything that is fully open tracing compliant, meaning that if you put the tracer as a global open tracing, it will, you're not closing functionality basically. Great. So right now the problem becomes, how do I add this active root span? So far I didn't really need it for anything in note, but it's starting to show that I might need that pretty soon. And I think the best place to have that is on the scope manager, because then, well, I'm not actually sure, because it can also be on the span, right? So the span knows its parents, because for the scope, I mean, kind of the tree of all the scopes, is not really the same as necessarily for the span. So your parent scope may not contain your parent span or something like that. So I'm actually not 100% sure. This may be another discussion completely and end up being unrelated to the scope manager, but yeah, it's really, the need is basically to be able to grab the root span, actually. And this is related to a sort of best practice that you're trying to develop a data dog around instrumentation. You mentioned decorating the root span, that there's cases where you want to be adding information at some root span as opposed to local root span, I guess I should say, right? It's not the root of the trace necessarily. Yes, because the way it's, we actually do it is, well, of course we have spans, and all these spans are part of a trace. So that would be your local trace. And then each of those local traces are combined together into like a distributed trace, like a real trace of your entire system. So in some cases, since we have these like strong concepts of traces, sometimes we need to enrich the trace itself. And for us, the trace is basically represented by the root span. So this is basically why we need to be able to access it. We have the same need in Elastic. We call it, currently we call it a transaction, this local root span, or sometimes we call it an entry span to not confuse it with that root-root span. But yeah, we have the same need to add certain metadata to the root span or the entry span. Yeah, I don't think it's a crazy concept, but I am noting it that there's been aspects, yeah, where the open tracing API currently doesn't provide accesses root span around that, or some concept of like, this is the process or service the span is running in, or some way of conceptualizing that like information. That's a place where at LightStep, for example, we tend to have some attributes we call them, but basically tags that are on every span that comes through a service, or a kind of concept like that. And I imagine other people have something similar. So I'm only bringing it up because this is surfacing as a feature in the JavaScript API, but it may be, I always wanna put a pin if we're seeing one API diverged to ask, is this really a JavaScript specific issue, or is this like a general issue? And we just are encountering it in JavaScript for the first time. We use it in all our agents, no matter the language, the concept of putting certain things up on the local group span. Cool, cool. So I think my only suggestion there would be like, I like this API and it looks good. I wonder if we could separate out, here is like a good continuation based implementation of the scope manager API. Here is like an additional concept we want to add to the open tracing specification around, root access or root scope access or something like that. Maybe make them slightly separate issues if we think this is going to be a sort of cross language issue. I don't wanna complicate the release candidate you're trying to make. I just wanna make sure we think about that in a cross language manner if we're gonna add it. Definitely, like I said, I pretty much just added it to, so that it's noticed and we can discuss it. But yeah, I'll remove those from there because it may even end up on something else. So definitely. I do think it's a good idea. Maybe we can open the issue on the spec repo or something like that. Yeah, I also was thinking, this isn't for right now, but once this is a little bit further along, well, first of all, I've been quiet but this sounds really frankly, really excited about this work. I think it's great to have, I think JavaScript is such a weird language that it kind of we know it's gonna demand something that isn't been quite like what's in Java or whatever. So I'm glad that we're having a session now before it's too late and I'm excited about it. It might be useful once we get a little further ahead to kind of mark the parts of the API that we actually aren't touching, the important parts of the API that we aren't touching, like certain kind of data model type things, stuff like that, just so that people who have bound to what we have now will have less anxiety about this landing. I think it's inevitable that we do something that's a breaking change in some way to the JavaScript, OpenTrace and JavaScript, and that's fine. Fine, but if we can try to cordon off the parts that are actually safe, that might be useful for people as the release candidate gets closer to landing. So just keeping that in mind. Because I actually think that most people will probably be pretty happy about the upgrade to this, but it'll be helpful to ease anxiety. It's just a prior experience of OpenTracing, like every time we've made a breaking change, it's been for a good reason, but naturally people kind of freak out about it. So I think things we can do to kind of minimize the freak out will be helpful. I'm not sure I understand what you mean by making it safe and reducing the freak out, basically. Well, I think if you zoom way in on these things that can feel like there are aspects of the proposal that are quite different, I think from what's there right now, probably frankly, because it's better, and that's great, but there are big swaths of the API that people will probably use or think about now that are essentially unchanged. And I think we should just, maybe there's no action right now. It's more a general request based on prior experience to try and isolate the part of this change that will actually affect people by explaining what won't affect people. Like people have mainly been adding tags and spans and stuff like that. Like that's probably not gonna be very much different at all. It's like for day in, day out use cases of API it probably won't affect things. It's mostly when you're actually integrating with frameworks and things like that where you have to think more about control flow that these sorts of changes will be more disruptive. But if someone's just taking the currently active span and adding some tags to it and then moving on, like that's not gonna feel, I assume that won't be that much different after this change has gone through this. I think one action is just as we are rolling with the release candidate here, we wanna look at how is this a breaking change? How, what is the upgrade path and be explicit about the upgrade path for existing code? And in the past in Java, for example, we've sometimes written shims or helper modules that smooth over some of that transition. Yeah, that's kind of what I'm getting at. And maybe, let me stop talking about solutions. The problem we had was open tracing Java. I won't do the whole archeology of it, but there are some design decisions made very early on that were just kind of a design by committee mistake. I'll just leave it at that. Like probably no one is that happy with what we did. And then we like fixed that with a change that ended up taking like a full year to roll out because there's a lot of anxiety about the change, some of which was somewhat legitimate, but I think it would have probably been better if we had moved a bit faster. When it was all said and done, the biggest complaint was that it took too long because we were trying to be too careful about it. And I think it would have been better if we'd just been like, listen, this is for garden variety code, it's not really gonna change. Like don't worry so much. We'll write these shims and kind of move on. And I'm just trying to figure out like how can you avoid that situation with this set of changes? And how can we make it so that, if there are a bunch of people who really understand this stuff well, they feel good about it. We kind of write the shims, recognize that most code doesn't even really change that much, which is the case with Java and move not like next week or something like that, but we move relatively quickly. I just don't want to see this stuff taking a year to land. I guess it's okay. I would say it's not like, I don't think there is a breaking change if I'm not mistaken. So it should be pretty smooth since there isn't no breaking change. The only kind of breaking change but it's not really breaking is that once you start using a scope manager and the reason it's not breaking it's because it's optional. So by default you get a no up. So it doesn't matter. But as soon as you put the scope manager in what is gonna happen? And that's from the specification, the open treason specification is that you will automatically, like each span will automatically be a child of the span in the current scope, which today is not the case in theory but there's no scope manager so it doesn't make sense anyway. So that's the only real change is that once you put a scope manager in then you may have some spans that get the parents that they didn't before or something like that. But so far it's pretty much the only breaking change. I guess that's a good point. Yeah, it's a change of behavior that you get by upgrading your API but you're right, it's not a breaking change. It's probably less likely for many reasons that this will cause a lot of anxiety. So hopefully I'm just a little bit traumatized from the job experience and it won't be relevant here. But yeah, that's a really good point. Thank you. The only call out there is yeah, let's make sure if we have some stuff that's experimental that also looks additive and so it would probably be good to have a release of the scope manager that only contained the parts that we think are necessary and well thought out and then have a second follow up release that maybe adds root or some other concept like that and make sure if it's just additive changes we're thinking separated into two releases so we have time to get it right. So how much would you trim? Like for sure the root and parent will not be in there. Would you also remove things like the bind and things like that? I mean, these are very useful but they can be done outside of the library pretty easily as well, it was just to avoid that everyone has to repeat this code because it's kind of involved. It's not a lot of lines of code but you have to know what you're doing to write it basically. I thought that code seemed fine. That just seemed like convenience that we were adding. Though I will say we have occasionally added some sugar and then paid for it later. So maybe we should review sugar or anything that's in there that's convenient but certainly code that everyone will have to write but is slightly tricky and really there's only one good way to write it. That sounds precisely like the thing that should be in the API. The only thing for me were things that were semantic differences especially if there are things that maybe put pressure on the tracer to have to now keep track of things or somehow influence your tracer implementation. Those are the parts where we wanna make sure we've done enough experimentation and put those concepts through their paces before releasing them, that's all. And I wouldn't wanna hold up this other work if that is looking like it's gonna take a little bit of time. Like if most of the risk is in new features, I'd rather ship the less risky part sooner and just get people using it. Makes sense. I can say that we have a scope manager already of course in Elastic APM that we made ourselves and that uses those two bind or it has a similar concept of those two bind things because it's essential in Node.js to be able to do that. This is a very Node.js specific thing of course. Yeah, cool. Well, it sounds like a next step would be a release candidate branch with a proposed scope manager from Rock. Let me know if you need any permissions to get that rolling. We're happy to help you get that set up. All right, for now, I think it should be fine. Eventually there will be that open tracing NPM user that will need to be an organization but that's only when we're ready to ship. So for now it's not the end of the world. But I had also a few questions myself about where a few things should go. Of course, for the first version it doesn't really matter but I think we can still open the discussion. So basically for context propagation you rely on the current asynchronous context and the problem is some libraries have their own internal task queues where they will run your code in a different asynchronous context meaning that you have to bind when using these libraries. One of the most popular ones is Bluebird. And what I was wondering is should these be patched directly in the scope manager? And that could even be in the abstract class probably because yeah, anyway, point is should this be in the scope manager itself or should it be up to the library user to do that basically? I would vote for keeping it outside of the scope manager simply because it's a maintenance nightmare to make sure these patches actually always work if a new version of Bluebird is released that changes the thing you are patching then it's breaking. Yeah, I think it's better to leave that up to the individual vendors in my opinion at least. Okay, I mean I totally agree and of course we know that this is also true for any integrations, so any automatic instrumentation for example. But also I mean, I would say you're basically distributing the nightmare basically by not putting it in the library itself because for sure it's something everyone will have to do. Because if you don't patch Bluebird, you lose your context. So it's simple as that. And even if you're not using Bluebird, there are very high chance you're using a library that's using Bluebird and at the end of the day you're using Bluebird. So the problem is basically that everyone will have to implement this and everyone will have the same nightmare but at the same time they won't collaborate together to address that. So maybe there are some bugs in one implementation, some bugs in another implementation and at the end of the day like all tracers will have a lot of bugs related to that because it's like you said, it's a very difficult problem to address and by having it centralized in open tracing itself, the advantage would be that if there's something needs to be fixed or some new library needs to be addressed, then it can all be done in there. I mean, of course it could not be in the core repository maybe, but I think it would benefit everyone to have it there. Of course we would need to have a lot of safeguards to make sure that for example, if Bluebird 5.x is released and it works differently or something like that, I mean, I think it's fine if a new version is released and it's not working meaning you lose what is not fine if it breaks. So the only concern I would have is to say it needs to be super safe. So as soon as anything fails, it should just continue execution, right? It should not throw or anything, but yeah, this is my take on it. Yeah, well, I agree also with that. So you can kind of see it from two angles, right? So yeah, I think maybe it would be really, really good if this could actually kind of live, I don't know if it's possible, but if this could live as a separate project that is not directly tied to open tracing. So even non-open tracing traces could also make use of this. And that would mean hopefully that we get even more eyes on it. I don't know if it's possible, this is possible, but if you could make the API in a way, so it's not, so it doesn't expect open tracing to be there, that would be the best scenario. Going forward, obviously, the right solution to this is to patch all the libraries that have this userline callback queue. This is a project that we kind of have worked on in the Node Foundation because with Asian Cooks, there is a provider's API that actually these libraries are supposed to use if they want to not lose context. And so we have opened a few PRs in these libraries to see if we can make them use this API. And if we can, then this problem will be solved by the library itself instead of we having to monkey patch things, which of course is the right solution, but that only works for Node 8.1 and above, obviously, because Asian Cooks needs to be there. Yes, and also you need, for sure, you need the support of that library's team, basically, to be able to do that. I think most of them are promised libraries anyway. I haven't really seen any other library where the context is really lost, or at least not a very commonly used one. PG Postgres, basically every database driver on the planet, at least one that uses TCP will probably have a socket pool, and that socket pool will have this problem. Most of them use this module called Generic Pool that they share, and Generic Pool will have this problem. So if you patch Generic Pool, you will fix it for most database drivers, or at least a big portion of them, but that has the same problem. Okay, so I think, yeah, I think for now we can basically, because this is not a concern for the first version, but yeah, I think eventually we could lead up to what you're saying, which is to work with the different maintainers. And in the meantime, we could have external projects basically to handle that. It would be nice if it's under the open tracing umbrella, but otherwise, I mean, these are, as long as it's like open source projects that anybody can use, and maybe some API to be able to use that easily, like, I don't know, passing these as kind of plugins to the scope manager or something like that. But yeah, for now, it's not really a concern. So this conversation is super rad, but I wanna call time since we've only got about 10 minutes left on this call. It sounds like we've got next steps that are pretty clear, but I'm excited about all of this additional stuff as well. So if that sounds good, everyone make sure. There's now a JavaScript getter room. I think these sub rooms are good. I do sometimes worry that maybe, because getter's interface is so terrible, people miss that there are these additional rooms where there's discussion going on. I don't totally know what to do about that, except perhaps occasionally promote them in the main room. But there is a- We could add a link to the JavaScript open tracing repo. That's good. I was gonna say we should probably link those sub rooms from each language reform. Yeah. So not just Java. I was going to add a table of contents to read me. That includes all of this good stuff. Yeah. But I think that's where this conversation should continue and I hope to see everybody there and I'm looking forward to your PR rock. Cool. So just final couple of minutes, other orders of business. Austin, you're asking about some ownership for some tool chains. Yeah. Who does anyone know who owns open tracing C-sharp, specifically the CI, the app bearer account? I think I know that. I think it's Christian Weiss. Okay. Is that not right? I think that's a good guess. Isabelle's talking, I think, but it's great. I'll jump back in in a moment. I'll come find you after this then, Ben. They might. I know that yesterday there was some talk about who owns the open tracing NPM user and whether that can be converted to an org. So I have access to that now, I think. I think an org makes sense, but I'm not entirely clear on what the differences are. One question there. What should the email be? We've done things in the past. I don't feel strongly about this at all, but created a distribution list on an email address opentracing.io that then sends off to various people who care just to multiplex it, but I don't feel strongly about it. Of course, that ends up being a skeleton key for password resets and stuff, so you have to be careful about it. I don't feel strongly about how we do it, but I'm happy to do that again if it's helpful. Cool. Also, it sounds like something we can discuss in the Gitter channel, but I'm glad you found the keys to that particular castle, Isabelle. We do keep losing these things. Perhaps we should have some documents somewhere where we write down some of this more banal. Yeah, in this case, the username was Ben Cronin, like username was Ben Cronin, so it's a huge hunt down. It does look like a clue. Oh my God. Yeah. Okay, we've got five minutes left. I know Carlos, you wanted to at least do a shout out about a PR for scope managers on Java or an issue. Yeah. Yeah, well, I don't know how many people here are familiar with Open Tracing Java today, but there's a pending request that I would like to get moving if possible for prior to do a second release candidate. Essentially, well, the link is in the document and it's about the possibility of activating a span context in addition to a span. And this is when you don't have any control over the lifetime of a span and you don't want to end up in this situation where you are passing an active span and it gets activated, but it's already finished and then you are trying to set tags or stuff over it on it and so it's not working. And it's kind of, I think it's very, in my very personal opinion, I think it could be something nice to have. It's kind of, it's like the polemical actually. So if there's anybody here familiar, it would like, I would love to get any feedback on that. I think it's something, it could be nice, a nice addition, but essentially one of the problems probably is that it could be adding some complexity to the API because then there's a current invariant where if you have a scope, you always have a span but then this could be breaking that. So yeah, if anybody has any kind of feedback or even if you guys are not familiar with the open tracing Java API, just let us know. I think we would always be happy to get some feedback for that. And I know Felix from Elastic cares about this issue a lot, Thomas, just to play out. He does, he's on vacation right now, he's back Monday. Okay, great. Yeah, maybe you can get another call together with Thomas and, or sorry, with Felix and Yuri. I think there are the two people who cared a lot about it, need to get sorted. Yeah, I think that's a great idea. Great. Okay, final couple of minutes before we all have to go. There were a line of other topics related to JavaScript and NPM that people feel like they got through all of those that they cared to. Are there any final questions on that front? I did see there was one note about working with OpenCensus on this. I think that's reasonable. We've been working with them around experimenting how we would merge Java APIs as a way of starting to like directly collaborate. I don't know if there's people on this call who also work with the Census team on the JavaScript side, but given the way things are going, yeah, I do think it's totally reasonable to check in with them and kind of see that we're all sort of rowing the same direction on some of these concepts. Or if we're not, like why not? Is there like a good reason? Like are there API decisions getting made that we could learn from over there? But I don't work personally with anyone who's working on JavaScript over there. I should say I don't know who's working on JavaScript on Census right now. I guess action item is to perhaps go get involved with that team and that repo. Perhaps once we've got a release candidate, a branch of ours cooking, we could point them at that and say, hey, what do you think? And if you want to do the patching of some of the modules like Blueprint, et cetera, somewhere, having it in a way that they also can use it would probably be a good idea that that's why I suggested that before. Yeah, I think that's a great idea. If we can just share it, start sharing components, it'd be brilliant. Hooray, okay, we're at the end. One final note, if you didn't add yourself to the attending list on the meeting notes, if you could do that, I appreciate it. And it's been lovely seeing all your lovely faces at you next time. Thank you. See you guys. See you.