Open Feature Project, 17 Aug 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature - Project Meeting, August 17, 2023

Description

Meeting notes: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/

OpenFeature website: https://openfeature.dev/

A

B

A

Guess we can get started, um uh I, don't see uh I'm, not sure. If anybody here um is new, um if you haven't been here before, if you haven't and you'd like to introduce yourself feel free to raise your hand uh digitally or physically there, and you want to introduce yourself.

B

A little bit late recently and I've adopted open filter in my company, open filter, yeah, hi, I'm software developer,.

C

Awesome yeah welcome nice to meet you thanks. Yeah.

A

Very cool it's been cool to have you around appreciate your reviews, especially your Java reviews have been really helpful. Lately, thanks um on your contributions, uh yeah I always appreciated. um Okay, I guess we can just get started so all yeah. This next point is pretty quick. I opened up possible um a proposal to discuss potentially a zero seven zero spec release. The changes are very small.

A

uh If you go to that issue, you'll see that the diff, um the only thing I'd like to also have in here uh is is Thomas's um uh weight, clear. Actually, that might be emerged already. I can't remember um it's merged, so we have that too. um So, there's one yeah. Sorry, there's one other remaining thing: it's not Thomas's uh a weight PR, but it's the changes to do with um uh events around context.

A

Changes in the client, which I think is a good idea, so that's open as a PR I'd like to get get that in as well, but anyway, the net changes are fairly small. We have one more provider State a couple of small changes, so it's nothing like the zero six zero release.

A

um Basically, if POC didn't the JavaScript SDK, it's it's pretty small. Just takes a a few minutes of implements, but I would like to get that out there at.

B

A

Point um hopefully, when we get that next um spec PR merged, take a look at that if you're interested, it only impacts the client but kind of important. The other thing I wanted to talk about today um is the react. Sdk. uh So yeah I have a link there to that proposal. Right now, I opened it in the jssdk contribs, um because I knew that would be a fairly easy place to implement.

A

It I think we can also implement it in uh the JS SDK um as a new package, um so I could move the whole issue if people feel like that's a better place for it, I think it may it it's possible. It will be slightly more difficult to implement there, but I'm, not I'm, not sure. um So.

A

The last thing I was going to say on that topic is if, if people are interested, I can actually try creating like a stub experimental package, either in the JS SDK or the contrib, so that then we can actually play around with releasing a you know: zero one, zero experimental version and we can keep releasing it. If we want, we can experiment with it play with it.

A

It'll it'll be released with the dash experimental like we were for the web SDK for a long time, so people can expect breaking changes and we can just try things out if we want um and be very explicit about the fact that it's experimental.

A

So if that's appealing to people, if people would like that- and they don't want to do the whole boilerplate with NX or or setting up the mono repo I'm happy to do that, that's really all I want to propose.

C

All right, nice um yeah once again, if the, if you have anything to add, please feel free to do it um looks like I'm next, but I. Don't have a ton on here so I'll rip through it quite quickly, um one I'm I'm in the process of working on an offap for provider metadata.

C

um We already have provider metadata, but it's only only supports uh provider name. At the moment, it's explicitly stated in the spec I'd like to propose that the provider can have like a mutable provider, metadata capabilities, I suppose, and the idea is like maybe during initialization it could set things like project environment, uh possibly like management, URL or whatever. The case may be that's consistent across all flag evaluations, it's important to be on the provider metadata, though, as opposed to flag flag metadata because of flag metadata.

C

If the flag evaluation fails, like you, don't get that in an after hook, for example, which means that you don't have that for like a Telemetry hook, for example. So there's a couple reasons for it: I'm trying to outline all of the kind of advantages, I think there's value to both, um because you still may need to have flag specific metadata, but there's definitely I think a case for more. You know, provider specific metadata as well. So look for that I'm like 80.

C

Through writing the proposal, um but I just need to kind of finish it up before I open up.

D

Mike I have a question about that. Sorry, so do you mean the provider would? Is it the provider sending its metadata to the open feature SDK or.

C

Itself is the way I would see it so like from the outside, like it'd, be mutable by the provider itself um so like during like initial initialization. It could maybe pull it from the management system and then set it, and then it would be.

C

You basically read only by consumers and hooks would be the idea um and that way like, for example, if we did like an open Telemetry hook as a at like a span attribute, we could set like this was the environment ID, where this fly came from, because right now we have fly key um which works okay, but in almost every system you can have multiple environments, which means there's different, like variations of the same flag and that becomes particularly challenging in like an error hook.

C

So if someone tries to evaluate a flag that doesn't exist, we get no metadata at all, um based on like our design patterns. So that's kind of the idea there. It's basically a slight extension of Pete's Original like flag metadata proposal.

D

So one thing that, where or flagsmith's going to be working on- and this has come up a few times- is something going sort of in the other direction. So when you initialize well thinking outside without open features for now, when people initialize our SDK, they want to be able to provide information about. Like you know, I, don't know what microservice that that is, that is running the place with SDK, that's making those flag, evaluations or the version of that platform, or something um that then gets sent back to drives me.

D

So they can see like you know like which service is doing more evaluations of a particular flag, or something like that. So maybe that, but that set. Maybe that sounds like a completely separate.

C

Yeah I would I mean, wouldn't that be like evaluation contacts like you could set like some of the more General stuff like globally, um and then also that could be. That's already captured and could be tracked.

D

It's well it it would. It's almost like you'd only want to set it once on on initialization and then and then it can't be changed kind of thing.

C

Yeah the global context: you could do it, you could mutate it technically, but.

D

A

Slight difference in intent, I think, like maybe I'm, not sure if this is, if I understand Ben's use case entirely like I, might need to know more, but, like evaluation context is specifically to be used as as input to evaluation right. So if that's not the category of information you're talking about, if there's just some other kind of metadata, you want to involve, and it's not a factor in evaluations.

A

The context might not be the right place for it and we might want some kind of other bag of data like like the kind you're talking about to pass um yeah, so I, don't know, I I could I could see it and then I think in that case, I think it is kind of related, um but I think we need to think about it. More and I'd like to understand the use case a little bit more.

D

So basically like for customers of ours, let's say they have like five microservice teams, all using the same blacksmith project to so they have shared Flags.

D

um They they want to be able to when they initialize the flags with SDK, announce which application it is that's doing the initialization so that when we capture things like flag evaluation, Analytics we're capturing what microservice it is. That's generated that evaluation event um or, like you know, and it would probably be like a dictionary or something that you could provide like a version number or something like that as well.

D

um You know or like we have customers that have like an IOS and Android application that have a shared project, but they want to know um yeah. So it's it's basically for it's well in our use case, it's primarily for analytics data, um but I think it would be useful for like like if you've got like if you're hooked up to open, Telemetry and you've got five microservices and they're all using the same environment. Key um and you you don't. You know, you've got no idea, um there's no way of telling those apart, essentially right.

E

I mean in that example, you could also just you could include. You can include that you know the version number or the service name or whatever separately in in the in the traces yeah in the baggage or whatever. I still think you would.

E

Although I I get I get what you're saying told that, like the the kind of this that maybe the the reason for including the information is different like it's not for flag evaluation, it's still I still think you, you could just put it in the context and because it'd probably be I I would imagine there'd be a lot of cases where you end up.

E

You do end up wanting to use it for for flag evaluation and from the con kind of the consumers perspective they're, like I, don't know, like my boss, told me well, like the platform team, told me I needed to include this information in the context so I'm going to stuff it in there and I'm, not really sure why you know.

D

It's It's Tricky like I, get. You know whether or you know whether you want um an actual like rigid thing of like this. Is the application name or something rather than you know, then going right? Oh, if you want to track the application name in the flysmith player analytics engine, you need to send a context with a key of underscore flag. Smith name. Do you know what I mean like I? Don't know.

E

If you would like, if you in the I, think in that context, you would probably end up providing a little a little like wrapper on top of the SDK. You know like like with open Telemetry, like different providers, have like I, think I think this is what they call distros, or something like that. Where, like, if I was dying, a trace, I would I wouldn't just say, like you know, in my documentation, here's the 55 different, open, Telemetry packages, you need to install and here's how you wire them together.

E

There's like a little thing that sits on top. That says, like we'll, do all the wiring up for you, you would you could do something similar with like open, Telemetry and Fox Smith, where you have a little flags of ocean Telemetry thing and you call it with like the service name and the version and all the rest of it and under the covers it ends up wiring the things up, but.

A

Yeah we're building exactly that. What you describe um internally, just so that the pre the configuration is done basically for all the teams that won't.

E

A

So I think that you're absolutely right, yeah.

C

Yeah, okay, so I'll open up that that pull request, uh hopefully in a little bit um pretty far along and then, if uh Ben. If you want to add any comments and see if it makes sense to include here or potentially elsewhere, I mean I, think there's a couple ways. We could handle your scenario but I'd like to kind of think through it a bit more and um if you can kind of Define the exact kind of data flow and use cases. I think that would help quite a.

D

Bit yeah sure I I think some of the other um larger providers offers something like that as well. So maybe there's a kind of common denominator emerging around that I'm, not sure I I. We need we haven't built it yet, so we need to kind of research it anyway. So okay.

C

Yeah yeah happy to take a look. It's probably a separate off-up then, and we could kind of look through it, but take a.

D

Look I think it would be uh cool.

C

All right, the next one I have is uh SDK readme improvements, so um I spent some time, basically looking at a lot of our readmes for sdks I kind of feel like it's easier for contributors to update the readme in the SDK repo, as opposed to going to a separate Dock, Place and updating it, and so there's a new template.

C

We've updated uh the JavaScript sdks both for node and for web with the new readme, a job has been updated and go has been updated and basically now in the docs there's a little script that like sucks them in from the different repos and then displays it in in the docs in a fairly nice. Looking way, we still need to do it in a few other sdks. So there are some probably open items there. If anyone is feels like taking a crack at updating the SDK or the readmeuse, please feel free to do that.

C

um Todd did up late, update the general template in the OR yesterday, so yeah. You can see an example. Todd posted it in the chat, um but then we can. Basically, if we have this nice template, we can start using it to uh potentially build like a support, Matrix and all that type of stuff in our docs uh in a fairly easy and consistent way. So um I think it's looking pretty decent, um but definitely you know any feedback that you have. Let me know I'm happy to make.

C

Some tweaks are still kind of working through it well um and then the last one is I started an implementation of basically uh and I. Don't have a good term for it yet, um but I'm calling it like runtime category detection.

C

This almost exclusively at this point affects the JavaScript sdks, because we have node in web and there's just subtle differences between the two um and so I have a pull request open right now, it's in a draft state right now, but it basically like if the provider explicitly sets like its category or intent and it doesn't match the SDK it will throw during basically registration um but I'd kind of like to get some some some other eyes on that, even though it's in a draft state right now, it's like. Do we like the terminology?

C

Is it okay to throw it's I? Think it's okay, because it's during initial registration we've talked about that a couple times, but um it is I think the first time that we would be throwing during any kind of you know, uh system Behavior, so um yeah if I can I'll link it in the uh chat here, but that's uh kind of an open question right now. That's why I haven't had a draft State, it's like it all works. It's just. Do we want.

B

C

We want this uh to behave in this way um and so feedback, and even some some of the terminology that we use I'd like to kind of think through that a bit so.

E

Would it be Todd, do you remember what we when we were talking about like originally doing like the client-side versus server side? There was like a: what did we call it like Paradigm or like there is some word we used.

C

A

Was a historical terminology: yeah yeah, we still use Paradigm in the in the spec, but that's because it's like it's, it's actually a different, a slightly different API right. So we have different availability of the context, but in in our glossary you can see like we actually still mentioned Paradigm, but we say generally, we also just um generally, since it's generally true that one Paradigm works on the client and one works on the server. We generally say, client and server, just because it makes things simpler for people right.

B

E

If you're gonna ask someone, is it, is it? Are you using it on the client or the server? Would we say which Paradigm are you using it on the client or the server? Is that the right word.

A

I think that's.

C

My challenge yeah I,.

A

I think this is like it's. It's tough, because I don't know that there's a super great term for it like I, when I think of client versus server I, think of different hosts but uh saying host, doesn't make sense when I think of I. Could you could also say run time, but then you're mixing in like well? Do you mean like Java, because Java's.

B

E

Like right, yeah I think I had a conversation with Mike about that like like. Is it node, because it's like yeah.

C

And I did switch that by the way which I.

E

C

That's a good change, but still it's like server versus client I. Think people understand that. But what is that like? What? What Cate, like I, put it under a category I think so far, but like it just it's a weird thing that should be easy: I, actually don't don't know. Maybe you should ask your Consulting buddies, Pete and see if there's a if you can coin a new term for it or something. But it's.

E

Let's just come up with like a brand new one uh I just read it I just listened to a really good conference. Talk about uh generative, Ai and apparently one of the best things to use, chat. Gbt for is naming things uh so I tried that and it was terrible, absolutely awful, so I I don't recommend using Chad GPT. For this.

C

Maybe it's just a bad prompt.

E

A

E

Like a Jedi mind trick now, everyone is going to use charging Beauty to come.

A

Up eat his bearish on on chat Bots. You heard it here. First.

D

Yeah, can you do cash invalidation or not laughs.

C

Yeah yeah and divide by zero and all that stuff do everything um yeah. It looks like uh that's it, for my topic looks like uh wired um added some stuff too.

A

So yeah let's go ahead and move on. Then why are you, did you want to say anything about this tracking analog stuff.

A

We can't hear you if, if you're talking, I'm, not sure um it might be a audio assume like issue.

A

um It looks like it looks like we have some audio issues potentially from fire, but um I know that uh he's worked on this stuff in the past and there is I think there was an issue open, um something something to definitely think about. uh If I yeah I don't want to I, don't wanna take up his time, but I think the idea is like basically tracking our goal events, so you could say like once, the user has reached a certain point.

A

We want to fire some kind of event um to indicate that which is is a feature that exists in a few sdks. That I'm aware of not all of them, though,.

E

So would this just be like just enough of like an API, that someone could, in theory, do the kind of like closer look on analytics and say, like you know, I, don't know. If you're doing like an A B test on the cover of the button, then you would. It would just be just enough API that you could fire an event to say they clicked the button and then you'd know whether the blue button performed better than the red button.

C

Yeah and that's what where it was saying and I I think that would make sense like the only thing I wouldn't want to do is like I, don't want to compete with segment or something you know or any of these other like event.

C

Tracking tools like I think it would only make sense in the context of like a flag evaluation um and if we like, add it in like flag metadata or something like that is kind of my initial thoughts here, I think other than that, it's like, then, we're really trending into like you know, user analytics and stuff like that which may be interesting, but that's a pretty big departure from what we've been working, but I do think there could be value and like if you wanted to do flag tracking and even if it's a tool that doesn't support it.

C

If you could register like uh you know, you know segment or whatever behind the scenes, and it's like you know, I do a flag details and possibly on that, there's like a track event or whatever, and that can you know encapsulates. Like the you know. Some of the stuff I was talking about that. Maybe the provider metadata and the flag, ID and all that stuff automatically and then those tools could like associate. Do the association.

E

I mean I the thing that I the thing that seems the thing that I can very much expect there to be a need for is to do the correlation right of saying this.

E

This flag was seen and this this thing happened right and if you didn't I think you need, there needs to be some connective tissue between the two, because otherwise um I think there's probably going to be a lot of a lot of systems where, if there isn't just a little bit of like thing to connect the two, then then, then it would be hard to do like an accurate kind of like assessment of, like you know, did this this user, like press this button, this user Exempted this Behavior?

E

Did they see the flag or didn't they right like um have I, have a feeling that a lot of systems like if you were building an A, B testing platform? If you, if you had an A B testing platform, and you wanted to use the open Future SDK for the decision flagging decision part, then um you'd want to be able to connect the two together I.

E

So I I can totally believe that that's something that is going to be really really important.

E

um The thing that I'm, not the thing that I personally I'm nervous about, is open, feature trying to implement a full-on like analytics, like the full API for doing um yeah for doing experimentation and I. Wonder I, wonder whether there's a way that we can kind of like solve that by just doing the connective tissue part like having some kind of like exposing some context. But then the other thing can some lovely some other Library can consume. Some other SDK can consume versus like trying to be that SDK.

C

E

I mean the other thought.

C

Is I I know, uh open Telemetry is working on just like a generic like event, API um I think it's actually quite far along because it's similar to logs it's just got a little bit more structure like maybe that's the thing that we could. You know leverage potentially uh I, think in.

A

C

Virus cases like that he's using post hog and post hog does the two like very closely together and it's kind of a bummer to say, use the openfeature SDK for feature flags and then use this other SDK to do the tracking so like. How could they maybe live together, but sorry go ahead.

A

um Yeah well, I just want to say uh wire. It seems it seeming to have some mic issues, but when Pete was initially describing his proposal um or describing his his understanding of The Proposal, it seems like wire, basically was, was agreeing with it. So yeah, some kind of minimal API to do tracking I think it makes sense. I think we want to make it fully.

A

Pluggable and I, don't know what that would look like, um but I think it would be like you'd be able to register, maybe the same provider as both your flag provider and a track provider or different ones.

A

I I and maybe the tracking provider is completely optional and just no Ops kind of like if you have no flag provider, but um we'd have to think about that a little bit more I, I I totally agree that open Telemetry could be a great um solution for this, but I would even want that to be pluggable and optional so that you could plug in a Telemetry events if you wanted to or segment or whatever, but again the same as Pete. My concern is that this isn't really our wheelhouse and I I.

A

Don't want to attempt to become like a full-featured solution here, um so I think it's we're. Gonna have to just be careful there. uh I don't want it to run away from run away from us.

E

When I think I agree that, like I, agree that if I was building an experimentation platform from scratch, I would definitely look at using open telemetry for the analytics part. But if you think about like all of the existing kind of systems that are out there, probably they're not using like if you like, I I, know that, like um like split, has like a basic analytics capability and like on the other side like optimizely, that's like their bread and butter.

E

If, if you had, if optimizely was using uh open feature to do the um the feature decision like the should I show, A or B part, no I, don't think that they would I, don't think you'd be able to maybe not at all but or definitely not like easily plug um just say to say, like oh yeah, just emit open, Telemetry events and optimizely we'll we'll pick those up right like it might be, though I'll surprise here or whatever the A B platform is just, doesn't hasn't what got that wiring done. So they would.

E

If I was if I was optimizely or split or whatever I would probably say like. Oh, it would be great if you could just use like we have this method that you're supposed to call want to want to use it as a or b. Can you just call this function please, rather than like, emit an open, Telemetry event and we'll do a bunch of wiring in our system to pick it up. Yeah.

A

100 I was only saying if you're, if you're not already doing it like that kind of tracking, you don't have something like optimized suit, then old hotel events might you might be able to build something simple yourself, because um but yeah I think that we would basically want to give full flexibility there. So I I agree with basically everything that's been said, I think there's a lot of there's a lot of potential value here. I just we got to be careful, I think to not to maintain a small scope.

A

If we decide to do this and maybe find some way of yeah defining where the responsibility ends and how far we want to go down that path.

E

I mean I think my my sense is that you could probably do like technically. Do it all with hooks um and some plumbing code and I I would almost like I would almost prefer to wait for like a few people to have done it that way and like see how it is used and like, like I, think in the in the JavaScript, um uh whatever they're called the standards committee. I can't remember the name of the TC, whatever stance Community, they have this.

E

This concept of, like cow paths and like looking to see like how like people, are naturally using like the ergonomics that they naturally want and then kind of like finding the cow path and then kind of like turning it into a road or whatever I I kind of feel like.

E

We should do the same and like at least have a few examples of of how people are doing this for for real before we start kind of trying to Define it, particularly because I don't think any of us have like a bunch of background in in like uh analytics and so I'm sure we would miss some stuff. That would be important and then and like redoing like taking an existing spec or implementation like redoing, it would be way harder than um waiting a little bit and then trying to get a better sense.

E

I feel like my like I'm always on these calls. I'm always like saying we should do less like the laziest I.

C

Mean I think maybe what we could do is kind of do it and sort of in parallel, because the proposal doesn't really hurt and we can leave it open for quite a while to start Gathering feedback and use cases and I think even where it may actually have that use case. Honestly, because he's done.

B

C

A bit with with post talk like how do those things wire up? What type of data do you want? um Yeah.

E

C

Be quite interesting to capture well.

E

I, don't know if you, if you can still hear us like do little Seance here um but like, and maybe we could try building a version of it just entirely in userland, okay, um like I, wonder if it's possible to build the whole thing in New Zealand using using Hooks and then um see like get a sense for how it works right like and and I think that would also kind of like pressure test, whether there's actually some extra thing that we need to add to.

C

This but I, don't think it's it's a hook right so like a hook would would like send an event for an evaluation which you can't there's a lot of value there, but I think what they'd be looking for like an A B testing world is like, with this new feature, enabled did it cause new user interaction? You know whatever right. So it's.

E

Like yes, the way I'm imagining doing it is a so let's. Let's take the optimizing example, the the API that I want to expose. Fundamentally the API that I want to expose to a consumer of this experimentation platform. Is they need to be able to ask like? Should I show, A or B?

E

That's the thing we already do, and they also need to be able to say that this Behavior occurred like this event like they clicked the button or they didn't click the button whatever right, um and they need to correlate the two to say like the same person that saw that saw this flag evaluation or experienced this flag of elevation also uh like exhibited this Behavior performed this this Behavior. So the way that I feel like you that I would I would try and build that with open. Future is um use, use a hook.

E

So you've got like your experiment at your analytic system and your future flag provider, which is, and it's kind of the same, and if the every time that you do one of these a b tests you the hook, would fire and you tell tell the experimentation platform in the current context. The current user saw feature, a uh sort of you know, sword feature a on or off whatever or so, a or or B, and then the user and then just the the the the firing.

E

The event that the thing happened or the thing didn't happen would just be entirely outside of open feature using like the whatever the optimize, the SDK and but the optimize. The SDK would be like. Oh okay, this thing happened and I know from this hook that this user did experience a or did experience, B and then you've kind of like connected the two together.

D

Just just one thing on that um I think post-hoc would be a dangerous would be maybe not good, because it's a because it's both things together. It kind of avoids a lot of those problems.

D

um The one thing that we've experienced- um and this is something that we get asked about all the time and we're going to start working on soon is everything that Pete said exactly as that. There's one there's one thing that there's one kind of primitive like method or something that we might need to implement, which is um when an anonymous user authenticates most analytics platforms have a.

B

D

A Primitive mechanism, to say this is an anonymous user, give them a hash and then experiment. This is the user login consistently maintain those experiments.

D

um Oh yeah, I know I know we work flags with is actually going to build that, because people are keep asking us to build it um because you, basically it's very hard not to break either like the experiment, Effectiveness or the user experience. Without that and and mo also most um platforms like amplitude or mix panel.

D

um They have like that's that's a core part of their workflow.

E

Wouldn't that just be like when you just do that by having a an extra bit of context, that's, like you know like the um like use, a fingerprint or something that is just always kind.

D

Of yes, the thing is I think different. um Different analytics platforms deal with that problem in different ways and I think actually, like mixpanel changed the way that they did it a few years ago.

D

um So I think the problem is you'd have to delegate how that worked. um I think you'd have to delegate that to Downstream to the provider um but effectively. All it is is it's and let them figure out whether they want to use the anonymously generated good or the key or whatever the authenticated user? But you, the problem is I. Think the thing is you you just don't want to get involved in that, but I think it might I'm worried about too much stuff getting sort of like shoved into the context.

D

I don't know, or also often those um identification. Events are like discreet things that happen. I, don't know. I I, don't know enough about how these we need someone on from, like you know, yeah, like mixed panel or adobe or whatever, to say oh yeah. This is how it works, but I think they they generally handle it roughly the same way but I think they'll have different specifics.

D

But if you're going to do analytics like this is something that we we lose customers from because they're like well, if you can't do that, we can't use it yeah.

C

Yeah so I I think maybe the way forward, then, is is to kind of create that oath app then, but we'll just keep it like a draft state to try to gather feedback and use cases, and maybe some some and then you know kind of look for maybe a prototype using as many like existing Primitives as possible and see kind of how that flow works and then, like pizza, then kind of look for like the cow path or you know seeing what what direction people would like to go, how common this is used.

C

How often it's requested and then figure out, you know kind of how we can proceed. There perfect sounds.

A

Good I think it's very.

C

Interesting as we get into a b testing and stuff, like that, you know, depending on how aggressive you want to go, but I do think that the future Flags in a b testing kind of go together quite.

D

Nicely I think it is like it's basically yeah the context and the evaluation results and that's basically it but there's definitely like dragons and stuff. It would be great if, if anyone had contacts at any of the you know, 10 big analytics firms who could say you know now. This is how you do it kind of thing that.

E

Would be I mean we can go, we can we could go and talk to vendors that we've talked to before, because all of them do do this. Like for the exact reason, you were just saying that Ben as a vendor like because people, it's like everything, hey every like every single customer at some point. Well, not every single customer like you're, always going to get customers they're like oh, we need to do analytics uh and like just from a business model perspective, they all want to be able to say they.

E

They do a b testing so that you know they can get there customer rather than having you know, optimizely do it with so anyway. I think like if we went and talked to Folks at launch Darkly or um for split or whatever I think we could get some um background, but maybe it would be better to kind.

D

Of It's Tricky as well, because you you can generally like split out SP, you know, there's the providers that do analytics and then the providers that don't and we like explicitly don't like as a decision um but I, think you know, even if we're using Lord of dark. You still might you know, there's probably a large portion of their customers that aren't using their analytics platform but are using like Adobe or whatever.

A

Segment or whatever yeah.

C

A

C

That's what I think the real value could be honestly, if you do it, because then it's like in your case, if you have a blacksmith provider, you could register you know one or maybe multiple like event, trackers or something that could fire out like automatically, which would be quite cool um and.

D

C

Could extend it to multiple it could be like it could, if you're using launch directly or whatever it could go to there and uh say like you know, because you could just register multiple event providers or whatever or tracking providers or whatever we want to go with, could be quite cool. I have to think about it.

C

Okay, um yeah, really interesting um yeah. uh If there's nothing else, um I'll post the thing one more time but yeah, it sounds like we have a plan to kind of go forward to prototype that and kind of keep tracking. It I think this one will take a little while, honestly, it's a pretty major topic that will require a lot of thought, but uh I think it's good to kind of get the ball rolling on it. It's.

E

Like the last part of like of open feature, I feel like.

C

Like yeah, to be honest, I would agree yeah.

A

Well, yeah I, guess: there's nothing else. We can. We can call it can.

E

I can I ask, can I go back to the react, SDK thing and if we've got so yeah sure I I replied to that issue and like we had some conversation about it, um I have this I have my little kind of like brush type implementation?

E

Is there any reason we couldn't just take it and use it? I guess like. Let me let me rephrase that well I'm trying to figure out what's the next step, to kind of like to move it move it along. Besides, like it feels like there's a few things that we're kind of like talking about making a decision on like should we do, we need support kind of service like rendering do we need to support um uh like do we want to use like suspense?

E

um So it's like a few things that were like I think we just need to make a decision one way or another and I'm trying to figure out. What's the how much of it? How much do we let it bake before we just say like okay, let's make a decision.

A

uh Personally, that's kind of why I was proposing like I'm I'm, happy just to make a stub package, um and we can even avoid publishing it until we.

C

Have some kind of agreement, but.

A

um I'm happy to like um you know, do the do the groundwork and whatever repo it fits in best, and then we can start like I'd be fine Pete. If you want to just dump your poc in there and and I mean if everybody looks at it and we agree it's like in the right direction, we can tweak it if everybody agrees, it needs to be totally changed and we can totally change it.

A

Then I mean like I I feel like it like putting something concrete there is, is it probably the best way to get going? uh So unless there's a like opposition to that, that's what I would propose.

C

No I think that's a good idea. Get the ball rolling! It's you know once you have something that people can comment and tweak it's way easier than a bunch of theoretical or or just text on a you know, markdown or something yeah. That's a good I personally think the SDK repo makes the most sense, because if I was going to look for like an SDK, that's where I would look um because I think it's it's worth the effort of seeing if we can get it working um but I'd be curious on people's thoughts.

C

There, like it, probably doesn't really matter, but.

E

Right I mean I, think.

C

E

Issue people look at npm they're not going to look in. They can look for the module and npm they're, not gonna I I I. If it was me, I wouldn't start looking in GitHub replays I'd start with, like looking in the open feature, names.

C

That's fair, yeah, I guess, and at that point it doesn't really matter um so.

A

Okay, yeah I, I, I I, think like if it, if all things are equal I would rather see it in the SDK repo. But if it, if it is harder to implement there, then I'll probably put it in contrib, so I'll I'll put I'll put it.

E

Go ahead, the only thing the only I I don't have a strong opinion either. The only like little thing I can think of is like for for that POC that I have there's a cut. There's like one or two um extra, like little like packages or providers that I created for testing purposes like there's that chaos provider that just kind of like lets you simulate kind of. Like um the you know, the the thing not returning values yet. Well, you know the provider not being ready or the provider, throwing an error.

E

um We would probably want that to be like it seems like it would be nice to also just kind of create that as just a um a general purpose thing that's available for testing and I would probably put that in the con troops.

E

Rob I, don't think that makes sense to put it but like to be honest, I'm the I'm, terrible at organizing code and I always just say just like put it all in one place, um but I, don't! My sense is that we wouldn't want to put that chaos provider in JS. Sdk we'd probably want it to stay in concert. Land yeah.

A

And we can, we can pull that apart too and, like I said I think maybe we'll start by not publishing anything I'll, just I'll just get like a working like bed to do some development and- and we can start publishing once we kind of kind of think that there's something reasonable and we'll publish it as Alpha, um but I guess that's what I'll do next so I'll I'll take that take away and then I'll, let you know when I have like something ready that you can dump code into Pete.

A

If you want to do that and then we can yeah.

E

Go from there all vice versa, if you want to just take it and um once you've got something ready, that's fine with me. I mean I'm very happy for my code to be used for sure.

A

Yeah, okay, then um just just pay me, your repo, so I make sure I get the right one like on slack and then I'll I'll, like maybe.

E

Yeah I linked it in the in the issue, but I'll ping it to you. Oh.

A

That's fine I'll find an issue either way. So, okay, one.

C

Thing that peaches reminded me of, though that I'll mention is, uh we did decide to create, like in-memory providers in each SDK, um so I'm in the process of doing that for JavaScript, as well just for like easier end-to-end tasks. It's also easier in that like getting started section of the readme, um so basically I'm kind of porting over what you've done.

C

I'm also kind of conforming to like what some of the other sdks have done already, um and so I'll link that back to the pr that you had opened, but then I think we were sort of that. We could probably even look at potentially deprecating that in memory one.

E

uh Yeah I think the the wait was that the right sorry I was trying to figure out if I was sharing. The right thing it was there today and that, like POC, is using I think this is wrong. Like.

E

I'd have to double check, but I think it's using um I, don't think this I think we ended up taking this and putting it into the SDK. This is the in-memory provider thing. There's.

C

One in contribs right now, but we're going to move it like officially into the SDK.

E

um Okay, yeah I'd have to look around and see like how it's used.

E

Yeah I guess it's not I, guess we'd yeah we'd want we'd want to change this because it is using like the the version like the the original version, because it's because it's like it's based off of some like a very old proof of concept that I did for for a reactor like way back before we had the the web, SDK and I just updated it. So this would need to change. To whatever is the the now? The official like in memory.

C

Yep that sounds good cool I'll I'll have more details on that. Soon too. Hopefully, I can get to it or.

C

Well, yeah, um it looks like we're we're basically through the list. Does anyone else have any last thoughts.

C

Yes, no okay, Thomas.

A

Thanks everyone yeah.

C

Cool, so just an FYI um there's a uh a wellness day, a diner Trace tomorrow, so Todd and I will be out of the office, um but we'll be back on actually coming to you too. So you need us, uh you may have to wait till Monday or this weekend we'll see how it goes. So all right, cool thanks. Everyone.

B

Talk to you later.

C