Open Feature Project, 1 Sep 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenFeature - Project meeting, September 1, 2022

Description

TODO: https://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ

OpenFeature website: https://open-feature.github.io/

A

Cool how's, the audio.

B

C

Hello how's it going.

D

Good late summers is really great today,.

B

Oh yeah, it's first time in the office for like two months.

B

I don't I don't have a us visa anymore, so the border guards give me a little bit of a hard time, not like a huge one, but.

D

Yeah I was looking at my office patches because I was like cleaning up stuff after moving in. I think I have seven of them. I have seven office batches for different offices for different buildings.

A

D

One is yeah, and one is for entry also to the detroit office.

B

They can't they can't get like, I guess, having global being too much of an infrastructural challenge.

D

It's not so much a company issue, so the company could do it, but as we are renting places in other people's buildings, we kind of have to rely on what they're doing.

B

Yeah right, hey dave.

E

Hey how's it going.

A

How are you doing it's good.

B

Is that a virtual background, or is that a real background.

E

It is yeah that belfast is not that nice. I can show you my real background. It's pretty um you'll see why I have a virtual one. It's it's pretty messy behind me. So suitcases and bags and kids toys.

A

The virtual one's working well done.

E

Yeah yeah, it's quite good, the company they put ones together for all the locations, so you can kind of see mountain view orlando. You know, there's like a bunch of them. That's.

D

E

C

E

Of the belfast skyline or certain buildings from them that.

B

E

B

Fire, I would, I wasn't sure if you were in an office- and there was just like there was a wall directed by his art.

E

On it, yeah yeah; no, no, it's all fake.

A

Well, um I could probably pick it up relatively soon. It looks like it may be. A late turnout today, um getting just.

D

Hey how's it going today, wonderful. How are you doing ah not too bad.

A

Morning, justin.

D

Good morning,.

A

All right: well, we could probably kick it off as you can see, todd- and I are in the office today- so not better on our usual spot, but uh hopefully we can still be effective here um dave. I have you penciled in for scribe for next time. Is that still good.

E

Yeah, I think that's good. Yes, sorry. I have to jump off at half past, so I thought it probably makes sense for me to do today.

A

Cool so james volunteered to do it he's just going to do it uh paper and pencil style and come back and put it back. So uh if you don't see any updates, that doesn't mean we're not taking notes. This means it's done non-traditionally.

A

So thanks james appreciate it um yeah. I suppose we could probably just go ahead and jump right into it. No newcomers today uh will probably be relatively quick. So if there's anyone that has any topics certainly feel free to add them.

A

uh I think you guys all probably have the links, so I won't bother sending in the channel um and yeah I'll just go ahead and kick it right off uh the first one is: we do have uh something for batteries that is volunteered to kind of act as like uh an open feature, social media manager, um and that will basically just be like uh right now.

A

She's opening up an issue in the community repo and it's got like a date on it and basically we can just add kind of noteworthy um comments to that issue and she's just gonna go through and schedule some like periodic tweets based on that throughout the two-week period, and then she'll do with the you know, open up a new issue after that, so just a kind of a simple way to get a couple.

A

You know noteworthy items out there, um and so, if you have anything, that's worth adding on there, please feel free to add it. um Some examples are, like you know: major spec releases blog posts, anything like that or conferences. So todd, for example, is going to be at devops world, and so that's going to be one of the items that we'll talk about on there.

A

So if you have any items, you know feel free to add that as a comment on that issue and we'll make sure that it gets out there, um I guess jumping right into it.

A

One of the big changes that we've been talking about- and this is probably been a long time coming and probably was uh honestly a mistake when I first named the repo, but we originally created a node sdk repo um that probably wasn't a good decision honestly, and so we've we've been talking about uh probably turning it into the js repo and also looking at what it would take to make it. So the sdk that we have now can run both server and client side.

A

If, if that's possible or if there needs to be, you know a split but at any rate, even if it was just server side, it still doesn't really make sense to have node in the title, since it can work theoretically in deno and arlentino. I guess is how you pronounce it- maybe even fun and stuff like that in the future, so like specifying the runtime in the repo name, probably doesn't make sense.

A

So there's an issue open right now that kind of tracks what it will take to make that migration github actually does a pretty nice job, also like redirecting and stuff. Once we do. That name change. But if you have any concerns there, there is an issue open right, now kind of listing out what it's going to take to do that migration, you know, feel free to you know, point out, you know your concern there and we can try to address that, but I think that's likely going to happen relatively soon.

A

The only really noteworthy change about that is the publishing package name would change, meaning that the you know you'd have to basically update to the new naming convention to receive new updates. So we'll try to make that clear. Like the release, notes and we'll have to make you know, let people know we'll package so would actually spit out and say, like you know, you're using a deprecated package, and then you can figure out how to uh to get the latest versions.

A

But uh that's that's just uh yeah in the works, I suppose- and so hopefully we'll be available uh soon. So if anyone.

B

Has any concerns, I guess now you.

A

Can talk about it too or feel free to comment on the issue.

B

I know I know um dan I'm meeting with you later today about maybe some potential issues with the um with just compatibility just to embed the the launch directory sdk.

B

So I think in general we're going to do pocs and research uh just before we kind of do this change, but I ideally we'd have a shared interface, a shared set of interfaces between the web and the back end. I mean against mike's earlier point, um regardless of whether or not we use one set of interfaces uh in javascript between the web and back ends. um We still want to rename this one, but whether or not we end up kind of sharing. Those interfaces is another question.

D

B

We're going to.

D

I'll probably take it to the github issue, also because I have other questions on um just naming it- the javascript sdk as you're kind of saying, with all the different run times like I know. In our case, I don't think we work out of the box with dino today, um so it's gonna get to be really interesting. Where open feature is saying, javascript sdk, but we might need different bindings or different platforms um depending on that runtime yeah yeah.

A

And we'll probably I mean make it have to or be very clear on the read name but like the naming convention of the repo, I suppose sets us up well for the future, and so I think, having that uh the flexibility is nice, but yeah. I mean to your point like I tested open feature briefly in dino uh and it worked, but obviously obviously then the providers would have to work and everything else too. So it's not just as simple as like the sdk works. It's the whole.

A

You know everything the whole ecosystem works, which is a little bit more challenging so.

D

Especially with the javascript ecosystem.

A

D

A

A rough state right now, I would say.

B

When is it not mr miller,.

A

All right, cool, yeah, so yeah feel free to just comment on there, but I think that I mean that is a good point for sure and I think uh for now I think we would still say node is the you know the recommended runtime for for what we've tested so far, but it does, you know, provide us the flexibility you know in the future for other runtimes um cool, uh I'm gonna skip just slightly around because uh I think we might lose dave in a little bit.

A

But one of the things that we wanted to do in terms of, like obviously being ready for, like you know, kubecon and that time frame, but also to kind of battle hard with the specification, is to build providers, um and so I've already created- and I started at the last community meeting, but there's a project board on github that tracks providers right now, um it's showing basically every company, that's registered as an interested party and a version for each sdk of a certain maturity level.

A

So the one kind of noteworthy omission there is python, that's not spec compliant yet, but the other ones are um so those ones you know have all been. You know defined on that project board and if we could uh basically start building out these providers, uh probably recommendation right now would be to to look at like the java one, uh it's probably the the the most mature. You know. It's got like some of the context stuff that todd was just working on that.

A

I think you'll talk about a bit um the the node or the javascript one is pretty far along and that one actually would also be a great one, because then we could start incorporating that back into the demo application. um So we don't have to kind of maintain two separate versions. We can kind of use the official provider in that one as well and the go one is in good shape.

A

The net one is is close, but the context, one that todd will talk about in a bit, uh there's an open pr right now and that will change a little bit so like you could certainly get started with building a provider. But there'll be a few things that we'll have to change uh in the real relatively near future.

A

B

A

I'm not a marketing person, but we could kind of brand it like. You know, provider september or something whatever you want to call it, but we're at a pretty critical part where we need to start building. uh You know providers over the next month or so so we can really test out make sure that the spec has what we need in there um and we won't need any. Like you know, breaking changes uh posts you know launch essentially.

A

Anything to add to that anyone.

B

E

I was just gonna say I mean do we need to kind of have like. I guess I can probably chase a few people internally here that we can start contributing some providers. But um like is there kind of a list or you know, do we do we want to kind of get names dying somewhere or, if he's going to do what, or is it just just weeks and see.

A

If we can actually do you want to, um can you pull up the board real, quick, so there's a couple of ways to kind of get started with this. um I thought I'm just going to show the screen quickly, but basically we have a project board to track it. So if you are going to work on one, um you know just basically let us know we can add the the references to it and move it to like.

A

You know the in progress column, so you can split up in just a second um just go to the main work.

B

And projects and.

A

Providers here.

A

Okay cool, so you can see them all listed out here. uh All of the different you know, vendors that have signed up as interested parties are all listed up there and they're. All you know different filters. You can also just click on one of the little tags. There little pills there to apply that as a filter as well.

A

But if you are working on one just let me know we can basically add all the tracking information and just throw it into like the in progress um and if, if you're, even like planning on doing it but haven't started yet we can throw it in just like that backlog section too, just to let people know and then, if it's someone, uh if it's a non-vendor, that's going to implement it so say, like I don't know some community member wanted to do, one for you know harness or launch darkly or whatever I'm going to add in that community badge there.

A

So we know that it's not like an official one, but it would be. You know it's better than nothing so that was kind of the plan there um we do. Also. Can you pull up the documentation, real, quick.

A

So in the docs we have some basic, uh like recommended naming conventions now for providers, uh so go to docs um providers here, and so, if you scroll down here a little bit, we have some, like you know, recommended naming for like how it looked in. You know the different package managers um things like that, and then I guess now, it's probably a good time to pivot to the technology section tab you wanna.

B

Show that quickly yeah. So um this is uh one of the topics for today now that we're here like like saying so, um we had this technology section earlier. This is just kind of links to um links to these sdks. uh Now it's a little bit more robust. So if you click one of them, um you can see providers, uh there's actually a button to add yours which just links the other doc, but um there's also kind of uh basically links to existing implementations. So this is the flag v provider. Then there's hooks as well.

B

um So it's really easy that this is just a react component with like a couple, really basic uh links and stuff to it. So you can open up the pr with your provider once you have it. They'll all be listed here for the appropriate language. I go to java, there's not a whole bunch here. um I did just recently finished the flag v provider for java, so we need to add it here, but yeah. That's that's! Basically how that works. You can. You can go into the docs repo, which is here.

B

This will redirect to it. uh I don't know hey, it stops.

B

um No, oh, that's an order, that's why so uh yeah the docs are here and you can see how to um open up one of those appears if you want, but it's just a couple, um just a couple lines of code to add your provider. So that's really or your hook. That's really all there is for that one.

B

I guess I can move on to the next uh thing I want to mention, which is.

B

I think this one f51, so this is a big discussion and I think it's worth quickly bringing up in this meeting, uh but basically it it was a proposal to it was based on a discussion here and then this is the associated pr, but essentially what it does is.

B

It adds a abstraction for um basically like a generic json uh node and that json node can like json, represent um an array, a structure or a primitive data type or null recursively, and it's pretty similar to what it's somewhat similar to what launch darkly has in terms of how they represent objects that are coming back from flag evaluations, but it's also similar to what protobuf uses to represent their their kind of deserialized objects in java, so basically in strongly type languages that don't support kind of generic object maps like javascript.

B

We need this kind of um this kind of structure to kind of represent object, uh types coming back from flag evaluation. So you can see what it looks like here, but it's just it's basically just a big object that can represent an arbitrary structure and um it's also going to be relevant for dot net. So I've been talking to ben evanson um who's, not uh today, I think he's on pto um about doing the same thing in dot net. I think there's actually a draft pr uh open for that.

B

So it's basically the exact same concept, uh so this should make it easier to do object, value resolution in any provider in java um without introducing a whole bunch of messy dependencies on the consumer like uh json or um or like a jakarta.

B

Json api implementation- um something like that. So that's.

A

Really all I have, I won't go through a demo.

B

Or anything like that, you can take a look at the pr if you want, but it's it's fairly straightforward. If you're familiar with java, I.

A

B

That's all I have to talk about today, yeah and it's probably just.

A

Quickly worth reiterating that the uh the the node sdk will be following the same pattern, so it's still there. Thank you. um So if you are going to implement a provider just be aware that this change will be breaking, it should make it easier. um But uh it's just one of those things that like it should be available soon either the end of this week or probably early next week, and then we should be pretty good to go. There cool uh any comments on any of that.

A

Perfect justin, I, like the background.

A

Nice all right um cool, so this one's actually kind of an interesting and, I think, a fairly exciting proposal. um I just yesterday finished up uh an open feature, enhancement proposal uh for transaction context, propagation, um it's just at the proposal stage. Right now, and so I will put a link in the notes- definitely check it out if you're interested, but it's it's kind of laying the foundation for for passing or for supporting uh transaction context, which would basically live throughout the life of a single like request.

A

Essentially, it's going to vary depending on you know the technology being used the frameworks and everything else like that, so the language will have to be a little bit a little bit vague, but I'd like to you know, implement uh some group of concepts in a couple different languages.

A

um This is not absolutely critical that we have it done um by the by cubecon, but it's one of those things that, like I'm already actually using it in like the demo application, because we were able to do it fairly easily um and it is extremely powerful and definitely useful in certain situations. So we can support it great. If not, we should at least talk about. uh You know some of the concerns and we can start talking. You know see if there's any you know required spec changes there shouldn't be.

A

It should just be enhancements to the existing specification and basically just defining like emerge orders things like that, but definitely take a look if you're interested in that topic. I think it's a pretty exciting one actually, and it definitely adds flexibility to people using tools that support. You know things like thread, local or continuous storage um and then the next one for me is open, telemetry.

A

So uh circling back to the open telemetry specification for semantic prevention um that pr has basically been open since, like may, I believe- and it's gotten some- it seems like a lot of the open, telemetry maintainers, uh maybe don't fully understand, feature planning. There's been a lot of hesitation on that pull request, and so I did update it yesterday to try to clarify like what I thought was the value being headed here um and try to even like you know, visualize what a a trace would look like and um you know try.

E

To kind of break it down.

A

uh As much as possible, if this is an area of interest to you, please check it out. You know, maybe even just add a comment of support or an area that I can clarify, uh because I I think it's basically at risk of potentially being closed. If we don't get a little bit more, uh I guess broad, you know community support for the concept, um so yeah definitely feedback. There would be very, very much appreciated and we'll try to add a link to the the notes here too.

A

If you want to just go directly to the the pull request.

A

uh That's it for me. Any questions on those topics.

B

Well uh looks like sky: you have a couple.

C

Hey guys, uh so I just wanted to point out that we've released a blog post on how to create a hook for the golang sdk um I'll, just paste the link into the chat.

C

If anyone has any feedback on it, I'm always happy to hear it, um and it would be good if we could get some more book posts of this nature. It's just kind of like a step-by-step tutorial that someone could take if they wanted to create a hook, um and following on from that, I think the next blog post, I'm gonna write, is a tutorial on how to configure a logger for the golang sdk and we we've actually got a pull request open right now for the go.

C

Sdk implementation and the the approach we've gone for is to use the existing logger api, which is effectively an an open api that anyone can integrate with their logger and there's already plenty of integrations with most of the popular loggers in the go community.

C

So this allows any application authors to just tie in their favorite logger and by default. If they, if they don't configure a logo, it will just fall back to the standard. Go log package um I'll paste the link for that in the chat as well. um If anyone has any feedback or any thing, they think could be a better approach list, then we could talk about it now or feel free to add some comments.

B

Yeah, I think in general, vlogging feels like a kind of orthogonal type concern like a side concern that I don't think we want to spec out, but we should I mean I think any sdk needs to think about how they're going to do vlogging. um I know justin's approach with java was to use slf 4j, which I think is a pretty good interface, pretty generic and well adopted. So I'm, okay with that, um but yeah, I think that's.

B

The kind of approach we need to take is just do the idiomatic thing for the language in the sdk keeping in mind, people don't want to always just throw things to the standard out. They usually have a logging solution in their application that they'd like to be able to inject or customize. So I think that's a that's in general. The right approach.

C

And if anyone thinks of any more kind of potential candidates for blog posts, then you can create an issue in the uh dobbs repo.

A

Perfect cool thanks guy. um I mean that that's it for topics. There's one thing that I'll circle back to, but I just want to open it up and see if there's any uh other topics that people like to discuss.

A

Okay cool, so I guess uh just like the last no. This is like an action item from the last one. Unfortunately, I don't have a great update yet, um but basically we need to figure out like what what we want to have basically released in the version one of the spec and what that represents, and so I've been trying to work on the language.

A

For that and from my perspective, ideally- uh and this is also why like creating as many providers as possible over the next month or so, is very important, but we want to make sure that uh when we do like the 1.0 release, this fact that the like application, like developer interfaces, are stable at that point. So that would be part of like the guarantee there that we're not going to just completely change with that. You know what the customer facing touch points look like.

A

um We can kind of talk about what it would mean from like a open future sdk to provider interface like like what that means, because technically like as long as we keep them in sync and kind of document like the versions requirements like we could probably get away with some breaking changes there. Obviously I think we want to keep that minimal because, as you see from even just that, the github project board like there's over 60 issues on there and that's a lot of providers to update.

A

So I think you know not not introducing breaking changes is gonna have to be a goal, but you know is that something that is a hard hard requirement. That's something we can kind of debate about, and you know once I create that issue. um Certainly you know, or now you know bring up your opinions on that and you know like I said I think we're going to avoid that where possible, and we need to avoid it where possible, but you know, is it? Is it do we have an opportunity to do it?

A

I guess and that's what we want to probably define in our goals. There um I'd also say that this should also encompass everything required to do majority of future flagging use cases um so like whatever that is, and I think we're basically there from a spec perspective um like you- can do virtually like any any require, like I'd say, probably like 90 percent of the use cases I've seen with future plugin, there are probably more advanced ones that you couldn't do possibly like.

A

You know, bulk evaluations and some of the eventing stuff, um but you know core future blog use cases I think, needs to be covered with their spec, and we also, I think, what would want to make sure that we say we aren't allowed to add features to this. This is not like we're freezing. You know. You know the spec like there's no no additions. I just think we would want to make it very clear that we're not going to introduce you know breaking changes to certain pieces.

D

So uh mike, what do you think if you go like ordered list of 60 and reach out to the contacts that we have to get an idea? What is really realistic for kubecon.

D

A

Yeah I'll see what I can do there um yeah for sure, and I think, like once we have confirmation for certain ones um I'll try to try my best to track it on the board. I think the hard part about the current setup is, I don't think it's going to be easy for others to maintain, which is going to be kind of a bummer like I don't think from a permission on github perspective, I can easily have others like kind of maintain their own state on the board.

A

It's so that that may be a challenge, um but yeah. If you do, um you know, especially for the the vendors that are on the call here. If that is, certain providers are going to be built, let me know and we'll just make sure, to tag it and move it appropriately um and then I'll try to figure out who the contacts are on the remaining ones and see if there's interest there. If not, we can just open it up for the community to see.

A

If you know someone wants to build and release it, and then, like I mentioned, we'll just tag that appropriately to make sure that it's it's clear um that it's not like a vendor supported one, um and it will also be represented, like that. I think on the docs page as well to make sure that there is a you know, there's some way of distinguishing between like an official one and one that's uh you know, community supported.

D

Yeah- and I think we can also work with david- that he can help. I mean it's like it's 60 providers like that. That's a lot, and maybe some of them are not even aware of what we are planning. So I think it's good to reach out to them. Anyways, because not everybody's joining all of the calls.

A

Yep yep absolutely I know that there's a few in the works already, um so I've talked to split about it and uh cloud views and then then we have, you know harness and watch directly on the call today.

A

So um as long as they're aware of it and- and you know, I guess, let me know and see what they're able to commit to- and I know it is a you know- kind of a big commitment, hopefully they're relatively easy, to build, and certainly let us know if there's any challenges that you run into, but um well also.

B

The most relevant provider for for every vendor is generally gonna. They don't know right, like they'll know where their, what their most popular languages are and stuff like that, so that could give them some guidance in terms of priority.

B

um You know, like the the the.net, may be more valuable for one vendor than another, depending on their customer breakdown. Obviously we want to get as many done as possible, but they may be able to kind of intelligently decide which providers they want to write based on their own metrics.

D

Which, I think is fair, I think open telemetry had the same issues where it eventually they ended up with some metrics, like keeping them all in sync, uh who provides who supports what, because, obviously, depending on your use cases, you might say well, I'm more or less focusing on the front end part than the back end part and it's totally legitimate. If this is what the tools primarily used, I unfortunately have to jump, um follow up on the rest, but uh good to be back.

B

Okay, yeah thanks.

A

See you later, okay, I mean, I think, that's that's more or less all the topics that I had on the agenda. It looks like that's all that has been added as well, so.

E

Sorry, just just a real quick kind of add on to that kind of last one I mean it's different, but just when you're talking about the spec and then the providers, I was kind of thinking like. If you look at ourselves like harness and launch darkly and a lot of companies, they tend to split provider or the split. The sdks is client side and server side, and I was kind of thinking like I don't think we account for that anywhere in the spec or we call it out and from an api point of view.

E

It maybe doesn't matter, but I'm wondering do we need to fit that in somewhere, um because I guess there's kind of maybe a an implication in terms of performance or the application consuming that provider like what that might do.

E

I think what we find most customers, who don't really care or get the difference between server side or client side. They kind of want to pick the language first, but um there may be some where it matters.

D

I have some concerns about the mobile world.

D

Specifically, I talked with the mobile engineers at ebay and they're, not going to use the java sdk for android they're, like we only use, we only want a kotlin one um and they'll probably use a more modern version of java than we use on the server side, um and I'm not I'm not yet sure that we're adequately representing mobile concerns in the spec, and so I I'd really love any like vendor hard knowledge there around mobile stuff and if we're taking all the right boxes, um I can jump in from lunchtime beside me to me what we've been looking at so far, and I thought it was kind of determined- was more server-side use cases.

D

Mobile is definitely a different setup entirely. um I guess from an interface perspective, it may not be as big like for our sdks, though it is because of battery concerns and other background pieces there. um So as far as open features go into, I haven't really dug into how that fits the mobile world.

A

Yeah, I think for now, like it'd, be nice, if we could make sure to take into account some of those requirements just to make sure that, like we're like back to like locking in a spec or something that we're not shooting ourselves in the foot there. But as long as you know, I think, for now we could just say like mobile is more or less out of scope and likely client is, unless we can figure out something relatively easy and that's something you know part of the research that we're looking at even later today.

A

Just to see um you know if it's, if it's something we can support with, you know minimal changes based on the spec that we already have it's something we could at least make available, and if it requires more work, then I guess we'll have to uh you know kind of break that down and see what it's going to take. I just I really want to avoid locking in the spec if we have, if this is going to introduce breaking changes. So that's my main concern there.

A

I don't think it's a big deal to say mobile's out of scope for for now, though, in terms of sdks and stuff.

B

As far as the web client like I was mentioning earlier- that's something we know that web is a big one. um So I want to, I think, in terms of priority. The web is is a bigger one than mobile. um I really would like to kind of suss out some of those things with web, so I'm looking forward to the conversation, the meeting that um we're gonna have with that I'm gonna have with dan, but then um maybe that'll elucidate some things that uh you know could help.

B

You know to help us either know what we need to change in the spec or know that this fact is good for the wider community. But um if you have any specific concerns, dave feel free to start a discussion or or find a relevant discussion. I could kind of point you towards stuff that exists on github now I think, but without being too hand, wavy the hope with um the hope, with the web with the java sdk, is that javascript sk. Pardon me is that basically, you just register a different provider.

B

So you'd have like a sorry, a web client provider for for harness and a backend javascript provider. For harness and you would just register the different provider that wraps the appropriate sdk in the appropriate context and really the only the only things really that are happening as far as the future sdk goes um are just vanilla, javascript stuff.

B

Now we may be missing, you know parts in either the javascript sdk or in the spec um to do that efficiently. While you know even considering things like.

D

B

The different the reality of the different runtimes, like the browsers.

B

The browser being minimum minimized and stuff like that, what impact that could have even on battery life, if you're, using the browser on mobile but there's a whole bunch of different concerns there to think about when we think about web. But the idea is at least the interfaces, hopefully are the same.

E

Yeah, I think that's fair, fair and I think foreign probably are you know, there's maybe not much like. Maybe there might be some additions, maybe there's something around being objective, local patches or whatever, but I think you know I don't think anything breaking. I was just wondering more. You know for the maybe for the provider developers do we need to kind of have some kind of indicator or type in there where they can indicate.

E

You know what it is so that if you're, if you're loading that up, if you pick that provider, you know kind of what it's doing, it's kind of offloading its evaluations remotely or it's doing them all internally in here.

B

A

But the sdks most of or all of them available right now do say like server side, flag evaluation, and then I guess once that, like javascript renaming, you know happens, we would just make it clear like how the different you know. Client versus server side, would work and install instructions and things like that. But right now yeah, it's basically all server side uh and just on those you know a.

B

Few technologies that we've talked about yeah to your point dave. We could maybe do some research about how to kind of alert people. Maybe there's some tooling. We could leverage an mpm or even at run time to kind of like say, hey, look. You may have registered a back-end provider in the front end or something like that. I I don't know what solutions there are for that. That's something we could kind of research just to put up some guard rails.

E

Yeah, I think that's all for and we we probably don't want to over protect people as well like. I think you want people to know what it's doing, and you know the impact that it may or may not have. um I think I just knew from sort of conversations we've had.

E

Quite often, this kind of topic gets confused and you know somebody's planning to put what's probably quite a heavyweight bit of processing code into you know, front down which isn't ever going to end well, you know, hopefully, people are doing enough research with this that they know that's. You know what they're doing.

B

A

Yeah any other topics.

A

All right, thanks, dave um yeah, I mean, if there's something else, I guess we can just go ahead and wrap up, uh definitely keep an eye out for uh that proposal.

A

I'm gonna try to wrap that up as soon as possible um and then yeah feel free to you know, provide feedback on that, but that should help kind of set the stage for, for the at least the hope for for kubecon that we're going to work towards, um and at least around that time frame in terms of you know what a what a spec uh or what, where we'd like that spec to be by that point- and you know a lot of it- does come back to just making sure that kind of battle hard net with providers and trying to use it for different.

A

You know test cases, you know that's where blog posts, maybe your good ideas, all that type of stuff, so really uh experiment with it and make sure that it's working uh it's just kind of intended um other than that, uh I think we're, probably good yeah. uh You know letting me on slack. If you need anything, uh see ya, get home.

B

Thanks guys, thanks all.

D

B