.Net Foundation Design Reviews, 1 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: .NET Design Review: WasmHttpHandler

Description

00:00:00 - Needs Work: Add a HTTP Message Handler to configure options in WASM Browser https://github.com/dotnet/runtime/issues/34168#issuecomment-607439446

A

A

A

A

There should be better, not all right so I know we have this one, so everything should be fine all right. So.

A

All right parquet, so then I would say: let's get started so who wants to give us the introduction, I.

B

Can go yeah. It sounds great, so pleasers shipping in billed as part of like as part of build in a as part of it like it uses webassembly, which currently lives in I, could sum most of the source code country's lives in the mono repo. Some of it will move over to the runtime 3.50 when it does HTTP. The underlying transport that it uses is the fetch API.

B

This is a browser, specific API and fetch has like a couple of interesting properties that, like users, might want to configure. So if you want to do like cores or if you want to do like caching or integrity checks and things of that, it's fairly common for do you want to configure this so the this API was basically about trying to surface some of these properties in a in a way that Datuk users can use and their programming in webassembly.

C

This proposal here enough just this- is this a reflection of what is already implemented inside mano today, or is this a different take.

B

C

B

So we have an ongoing PR that attempts to change some of these things to sort of map this. But you know, based on the feedback that we received from here, or maybe like even alternate designs, we might change that current implementation.

D

To high-level questions, one I, imagine there's more measurable, walkthrough the individual members here, but I.

D

Imagine, there's more customization, that's actually possible with the fetch API that has exposed here and so I'm wondering if hey that's true and if be, it is true how we arrived at these five things to configure, and my second question is just a naming one on the handler itself- I'm still a little confused about when we're choosing to use webassembly versus something related to the browser or the specific API, that's being used if we're referring to web assembly in general as the architecture or the instructions that it's a little strange to me.

D

That we did include that in the name of the handler.

B

So I think like off the API set such exposes. There was only one additional one which I didn't bring up. I can pull that up like it's in the linked issue in the link here that says fetch API, but most of the other ones were there and there's no reason. I just picked the one side that we sort of needed as part of blazer and I think we're commonly used by applications.

B

Let me go. Look it up. I know so. I think the one that was missing is like referee and referee policy, which I haven't seen like used commonly, but in another I'd look at it like this also keep alive, which might be interesting to like bring over things like, and some of the other properties that, like the fetch, API users are exposed differently.

B

So, for example, like you can specify like its way to abort the current request, like you know in this case, like you, would just use a cancellation token on the like on the HP, send miss and async instead and like the implementation sort of converts it into that option same way, you like you, would use like the HP request message, short headers or the content or header. So let's set the headers property. These were the ones that sort of like didn't really map to like.net concepts, so there mmm expose, if.

C

You think there's a reasonable way of having a loosely typed care of like jail thing where you know, there's a dictionary that you can use to pass other arbitrary parameters.

B

That would be interesting because, like so for one like browsers, you tend to change, maybe more frequently than us or like outer band from us. So it might be interesting for us to sort of consider it just in case like the ad, like one other option, and you know, users don't have to wait and I died here or so before they can start like using it and yeah and, like sometimes browsers also tend to like bring in experimental features that might be interesting to for an application developer.

B

So having a loosely typed option that basically gives you get out of jail. Free might be interesting.

D

Handlers like you should be client handler sockets. They should be here and they're waiting to be and they all have properties property. That's an addition area from string to object, yeah useful to me for the most part they don't use it, but I think they were added with the idea that it could be escape. Hatch like that. Maybe it would make sense here as well. Well,.

C

Unfortunately, we would need to know which subset of the keys to serialize present over to install script cycle. So we probably would need something that was more clearly a dictionary of fetch options, rather than other things which might not even be serializable.

D

Sure it could be I mean you could imagine various schemes. Rather it could be that you come up with the naming convention for keys. It could be that there is a fetch options. Entry in that properties, which then you know, is itself another dictionary or it could be something entirely else entirely. Different I just wanted to point out that they did exist in some fashion, yeah, cool and.

B

So for the naming itself, like I I, think there was like some offline discussion about it and but like we've, had like multiple naming issues about this and I just went with the one that was like suggested in like the offline discussion, but like it's not clear to me like this is the best name like browser. I should be hundred sounds just about fine to me.

A

Yeah, my other concern is you have very generic names for the items, but you have requests. Cash requests. Credentials requests no, but they all specific to this handler and all of these things are dumped into the into the namespace that everybody else is using, but is already pretty busy. So my people have followed to either have a naming convention for the enum, so they're all tied together or if you're convinced that these enums are used outside of the web assembly handler.

A

Then you know using the current name, which is also fine but they're very specific to the center. Then I'd either have a prefix for those idioms or I would maybe even put the whole stuff in its own namespace, because I mean the other question is if it's just these four types, I think it's fine, but to Stevens earlier porn like if we extend the API service over time and then eventually we have 10 15, 20 type, then having them all in the root. Namespace might be a bad idea.

B

So would it be something like system there should be pep assembly, so our system, and it should be um causa like.

A

Yeah we just say like I mean whatever we call it. I mean I. Think if we call back its assembly, HTTP handler I think is reasonable. The namespace is called that assembly, like whatever name you pick, whether it's browser of f assembly I would just use it as a prefix for HTTP answer and it's the name of the namespace okay.

B

E

Would this be usable in like an electron environment.

C

All right, it really depends on how exactly you're hosting don't know inside electron. So if you are using electron to open in an HTML file that contains a blazer application, then yeah it would work identically because it would just load on whether assembly. On the other hand, if you are using the way that we've suggested to host blazer in electron, then web assembly is not involved at all in that situation, and so you and user there.

B

So, like another sort of thing that Corey pointed out in the comments, because there were a couple of comments that he had was that all of these options are per request pieces so like basically, when you do a fetch, you they're all options versus like the handler is like it's more long-lived, and you know his assertion was to like how we considered like using a derive HTTP request message. The very could configure it, but like obviously that has its downfalls.

B

C

Hold on enough, maybe I'm misremembering, how these things wire up together. Are you saying in the default case a person can create an HTTP handler and then use it to send multiple requests? Yes, because there's.

F

No client instance.

C

Itself, like a certain something like an integrity, doesn't really make sense, because that you would never have the same integrity value for unrelated requests right.

E

Yeah I believe the request message also has a dictionary of streetand objects that might.

F

E

Usable here to.

D

Occasion that was sorry.

E

D

Think like, instead of having the actual properties, you can imagine having static keys that were used to index into.

F

That or something that is precisely where this entire thing started,.

C

Originally, that was the exact information implementation we originally proposed, but the string Li tightness of it people were not happy about got it, but you know there are good reasons for and I still think. That's quite sensible approach.

E

So another approach is to have a type derived from HTTP request, message and I. Think we've done that yet.

G

Okay I mean that would completely change the way that you work with the type wouldn't it because you can't use HTTP client to build the messages for you anymore, yeah.

E

But presumably if you are setting these per request, then whoever's making, the request has to know that they're working with this type already.

C

D

So what is the sum of something like integrity to Steve's point like? Does that mean that people will not be using the convenience methods on HTTP client? No.

C

If they want to set these properties right, okay,.

D

So I mean just from the get-go if we expect that these to be tweaked for every request that gets sent pretty about a hand, there's not the right place. Okay,.

A

So which make sure these is it? Is that just integrity or is it stool for all the properties that you put a bad luck? Well,.

C

The underlying fetch API is best to by the JavaScript fetch. Api is based around the idea that you set all the options you want for every request that you send there isn't any concept of anywhere to store these options for reuse, and so it does make sense for us to reflect that kind of design on the dotnet side. So, for the same reasons that it's designed that way on JavaScript, you just there's. No reason why any two requests should have the same request. Cache policy or the same request, no same integrity and.

A

There cuz, they would probably go with a different approach. I would probably do a separate namespace I would put an extension type there that just defines extension methods over the request message and then maybe have some convenience api's that are directly against h-2b, enter that you know, I, don't know I named appropriately. You know get with integrity or something like this. Where he'd already said these things, so you don't have to construct a message for every single thing by hand, but then maybe we don't even need new toys.

A

Maybe we can just define everything as extension methods and then the underlying thing could be effectively string leads all right, but don't have to give of them. That is precisely the original proposal. Yeah.

B

Have you started with that and then I think like the concern? Was that, like it didn't, feel strong, they type enough cuz I, don't know a good.

C

Justification like there's nothing not strongly typed about it. They all the API is that developers use of regular methods that feel as strongly typed as anything else. It's just an internal implementation detail that we're representing stuff in the dictionary I.

A

Mean you could have an options type right, I mean it's just that you know, instead of exposing them all this set methods on the handler. You can also just have an option start up and then every letter, no that assembly option. So you put all the things as regular properties and then the only person this option in in one of those extension methods, and then this thing does whatever it does right. So it could feel very similar to regular properties on the time right.

E

A

C

I mean: do you mean you to find some type? Let's call it fetch options, for example, and then you're saying the underlying representation is that the HTTP request message has a property's entry called fetch options or something that is of type fetch options, and then we've got a bunch of extension methods that deal with creating that entry in the dictionary if it doesn't exist and then mutating its properties.

A

Sort of whatever they see would suggest is. We would have an extension method over message and some extension methods over the existing HTTP client that effectively take this option class and then effectively the user would define you know fetch options and then I can either shared across multiple requests and just pass in the same and since every single time, or they can new up one every single time and then pass that to the by the get method. That has an overload the post person.

A

That has an overload- and you know, maybe their message itself as a set such options method to find it.

A

They all sound good to me. That seems like at least that's very closely to what you said, but if you actually think then I don't know, the JavaScript API looks like what I assume you have affected equivalent of get and post, and then you pass in the options either directly or as already a an options type right. Well, they.

C

On the JavaScript side is just called fetching: you specify method as one of the options, but yeah it's more or less the same, so that spaces then.

A

The comment of send right there.

A

And maybe that's what we do then so.

E

What does that? Give us versus deriving from HTTP request message.

A

It would be very similar right, I mean because even if you extend the message directly, you generally don't want to construct the messages by hand, but you'd still probably want some convenience overload director. There should be climber, you can just say get and then pass and whatever you want to pass it right, rather than having to say, send and then construct the message sent the method and do all the other stuff. That is like four lines of code line. Most.

D

Likely have a derive type or some scheme involving properties since would have to work its way down to the underlying handler you're. Just saying it wouldn't be public right.

A

Yeah, would you suggest we have a generic property back somewhere that they introduced on the base? So we can, you know, have to do crazy, gymnastic salesman, right, I,.

E

Think the convenient methods like they get and post won't allow you to set any of these currently I think we would need all new overloads for those. So the only way someone would be able to set any of these is to use the full. You know construct their own message and call send.

D

If I understand correctly, the extension method proposal was to add, like get overloads, get async overloads that took these as parameters was that good proposal, yeah yeah.

A

Extreme for the common ones right and then I would still have a send one that just takes the entire options class right so that you know you always have the ability passing everything whatever we had in the future.

D

Could you could you click on the fetch, API link, I'm curious? What the actual browser API looks like.

B

So maybe you want to click on the web. They are that one, because that has the actual sorry you're.

H

Right Howard.

B

H

B

Interfaces like the first link under fetch interfaces. This one here will maneuver okay, yeah yeah cause. That's like the actual method.

C

Yeah that they here so everything that's listed on your annette method had his body and so on. Those are all the options.

B

Anything like what a down they might have an example of what this ends up. Looking like.

D

It's the downside to the extension method approach is if we do expect this to evolve, that's easy for javascript, it's not quite as easy for a.

H

D

With fixed number of arguments.

A

We would just have a fetch options: class, whatever just add the send overload it just takes that one right, then they could be SDI properties, you always get it in I mean a pseudonym Charlie show what the implementation does like I mean. How do you plant the stuff to what.

D

I'll stay with this. Would this will end up at some point. This needs to be on the HTTP request message, because that's what gets handed off to the handler so somehow this ends up either in a known property name on the HTTP request: message that the this particular handler looks for under the covers, or you have a derive type HP request message that this handler looks. You know it tries to cast it to that thing, to fetch the options off, but but in some ways they perform.

D

They have to end up on that request, message, object and.

E

How common is it for people to actually set these.

C

It's not super common I would say with we're talking, probably like it's not just a few percent, but it's not 50 percent.

C

Either it's going to be I, don't know, like imagine a quarter of the time you want to do something like this and they'll, be certain people whose applications, for whatever reason, require them to do this every single time, because you know their server requires them to, but they've got their own reasons to, and in that case we would just say, like you have to make your own helper methods that wrap, get and post and search within your own ways would.

E

It be worth it, the handler can have defaults, I.

C

I, don't know like we we've kind of did that in the past and it it's confused people like we. We did it with just a static which was awful, but even if it was on the handler, that's kind of us I guess the same kind of thing as a static. It's just a bit more scoped than that and unless you've got a good reason for wanting to reuse these values, then the value of it is it's a bit small. Whereas what you just said about making a fetch options, objects that you can be used.

C

If you want to that. That perhaps is a little more obvious.

D

I think I've been finder to not have I mean personally I've, been glad to not have extension methods and just have either a fetch options bag that we put into an O named property on the message or a drive property type, both of them named appropriately to connote they're only relevant to when you're. You know, operating in the scenario where you're, using this underlying handler.

D

If we expose the extension methods, I'd be a little concerned that we'd have to make the name so unwieldy that it would just be this long, gibberish thing because we have to. We wouldn't want someone calling it outside of this domain. That's.

A

Why I would put them in different experience, but that's I would say we would have system that is sheepy dot. That say that the same way, and so you wouldn't have sever using for that new sphere in order to see those extension methods, yeah I mean I, hear what you're saying, though, like it's I mean my concern with that. If you derive from I, think Hendra is fine, because the hunter is the thing that you have in one place.

A

Right deriving from message seems odd, because it will break compositionality right so, for example, all the extension methods that we have defined right now. For you know the consolidation stuff, there's code symbols in them. The people, basically just you know hand, create messages right and like basically everybody who has a new, stable right now for a message to do some advanced stuff. They would now have to change it. You knew web assembly message or something right which.

D

A

Holds phone if.

D

They wanted these. This is the extension methods they have to change the calls to the current ones to be the extension methods instead, either way they're changing them. I.

A

Guess it's yeah yeah! Yes,.

C

It is if someone's got some library that produces HTTP request messages. Somehow, then you know they. They would be able to use that with the extension methods, but they wouldn't be able to use it if there was a different type. But I don't really know that there are very common cases where people do that. So.

E

That's why I'm wondering if default values on the handler might be valuable because all of the existing code that uses HTTP client, if all you want to do, is set. You know a cache value for all of your requests. Then your code could be portable across multiple handlers, like the JSON extensions. Would all work I.

A

Mean caching seems still somewhat specific, but I. Think credential is one of those things that you probably would want, but I could see that being ugly people want to do yeah, I.

C

Agree that having some way of doing defaults could be useful for some people, but that's kind of a that's more nice to have that. Having a way of doing stuff on the per request basis is the essential thing. Yeah I would yeah I'm.

E

Fine not having the the statics I agree with Stephen, though I think that extension methods probably aren't going to be very useful here.

E

Or at least they're not going to have the effect of keeping the same composition that we have today well.

G

But if extension methods are just there to give you compile safety on setting the property names and then they're just shoving it in the dictionary that would still provide the value with being implementation, detail, string, ly typed, but most people's code samples would be strongly typed.

E

Yes, it's more of a nice to have not a not a need to have no great.

C

It depends what alternative you are suggesting he, what what would be the usage pattern if they don't exist. My.

E

Preference would be a derived type of HTTP request message.

C

Okay, well, if that derive type, is the thing that carries the information, then the extension methods are irrelevant right, because if you've already created your HTTP request message and it's not that type, then you've got no way of doing this.

A

Well, you could say that the extension was just a fine evolved HTTP handler for common operations. Well, you could send a send a Singh that takes the options as arguments right and then that just constructs the derive type of the of the of the HTTP. You know request message and then they just passing it on so.

C

You're saying the derive type, there is not a magic type. As far as the the underlying handler is concerned, the derive type is just a shorthand way of populating the properties dictionary. Why.

A

This is magic in the sense that that's what the handler would look for right. If the handler have to process a message, they would just try to don't cast it to the webassembly request message and there and see what the properties that said there that they're not, then you would just use the default okay so that.

C

Being the case there's, nobody could ever use this with a regular HTTP request message and that being the case, what's the while the extension methods doing what are they extending extensions of HTTP.

A

Client, they were just being sent a sink, or you know, post a sink.

C

A

Isn't shortened.

C

A

C

A

They would just make the comment. Okay, it's slightly shorter right, so people don't have to construct the message, but well yeah I'd probably doesn't buy you much. It just makes the probably the hello world look slightly more appealing. Yeah.

C

Well, I would consider the derive type to be sufficient. It does mean that everyone has to write. You know four lines of code to do this, but it's uncommon enough, except.

A

You can just it's the thing that I would just say that even they'd be just were asked to do the extension methods for Jason sterilization. It's also four lines of code, most of the time right or from many of the things, that's right and yeah. If you write it often enough, it's it's it's annoying right. So.

F

A

You think that all these things are rare enough, then I think that's fine, so.

E

What is the the common content type that you would use with this? Would it be JSON now.

C

This is for any kind of request, yeah.

E

I mean it can work for anything obviously but like what is the common one, because extension methods or a derived request type, neither of them would support like the the new JSON extensions right, we would have to add additional extension methods that worked for JSON and this, and it's going to kind of balloon into this large thing it seems like is the common way of using this is to just send some JSON somewhere that you might need to reconstruct the requests yourself anyway. Well.

A

I mean you could say that you know. If what you've just said is right, then you would just say: okay, then we would say the common case. Is you don't have to pass anything in so the regular HTTP, client messages and methods will work for you if you want to and then also or extension methods will work just fine too, but now, let's say you need to set the cache policy. I need to set credentials.

A

If you wouldn't use Jason, you would just construct the assembly request message by hand, and if you do you chase, and it just means you call the extension method. We have over.

A

You know the: what is it the content or whatever we have rights you can just basically read or send, as as as a one-liner by jesus said, the content as JSON content, or you basically say when you when you're reading, you get the message and then you just say you know read as Jason I'd, rather that using the extension methods to find over it should be fine, so there's still compose.

A

It just means that it's all predicated on the fact that it is rare right if it's very, very common, that people need to pass in these things, and you need top-level extension message. An HTTP client that deal with that. Then I would agree with you that it falls apart.

A

If we think that most of the time we wouldn't even define this extension methods over HTTP client, because we expect the vast majority of people get away with not selling these properties and it's a very rare thing to set them and the way you set them is by using the message, then I think in components. Well enough. I.

C

Wasn't trying to suggest it? So rather you know you'd not see it in the wild. I think you know, I was estimating before, like maybe a third of the time. People want to do this, so I think it. It is common enough that that people will demand it.

C

Is it really impractical to have a set of extra of loads on the the HTTP adjacent api's that are going to work with this in some way.

A

No, the problem would be fine. It's just a question now dependency matrix right because we yeah I'd known exactly yeah I mean it depends on how these things are shipped right. So if you ship this thing, isn't it's a loan? You get packaged and we should also send a package and always wouldn't have to depend on yours, for example, right. That's just the the end result of that yeah and then also needs of ours, wants to go in box, uses to go in box as well current, but yeah I. Think it's fine.

A

If you just have to overall to take some data. That would be fine, I think.

G

And, technically speaking, they wouldn't need to depend on each other. They would just need similar extension shapes and a lot of repeated code. So, depending on what our goals were, we could work around it.

D

I'm wondering if we're gonna find similar issues with other handlers, as we think about more about ios and android and whatnot. If we're gonna find that this is a common pattern of needing to supply additional handler specific data with each request and.

A

D

So it's one thing: I think, to create a specialized request, message or keys into a property bag. That's another thing to duplicate a whole bunch of methods for issuing requests for each. I.

H

Mean I can think of this is maybe slightly during the conversation, but I can think of cases where that's true today, where users users have the expectation that they can can or should be able to configure various HTTP client handler related settings on a forward basis and it causes them a lot of pain, yeah.

G

Like it sort of feels taking Steve's thing and running with it like, we will possibly want like an options. Builder type- or we just say it's the dictionary and then we take the existing HTTP client methods and we add overloads that take you know a dictionary to merge them with a dictionary that it puts on the request as it builds it.

G

So then you would have your your application model, specific properties that you need to add and then using a strongly typed builder or whatever, and then it merges them in on the request on the fly.

G

It still won't help things like the Jason extension methods unless we also add the options pass-through on those which we could certainly do, but that's probably there possibly a more extensible thing if we think we're gonna need to do this six or seven times.

C

These are kind of the other kind of design shape that occurs to me is to following on from the options builder thing you mentioned there. If all of these different get and post method were conventionally, not the thing that actually issues the request, but rather there's something that returns an HTTP request message, so you would your normal usage would be VAR, something equals a wait.

C

My client dot gets blah blah blah and then you'd have dots and async after it, and if you want to in between the gate and the send async, you could churn on there's many other builder calls as you like the extension methods that do handler specific things.

C

C

Know it's probably too late to that I mean.

B

A

Add those I mean the the question is also how this stuff eventually composes right. If the expectation is that, ultimately, you have effectively what amongst to either key value back somewhere at the very bottom and then, if the expectation is you construct the the handler that did knows about certain things and then in the message you just put in whatever you want, then I think that's fine design and then effectively.

A

That means we just have to have some sort of base type that all these options can derive from, and then you know every single method that takes you know everything. Everything is specialized method effectively. That we currently have would just take an optional argument. That is effectively whatever additional things you want to stuff in, and it just punches it on the underlying message enter message and the underlying message, and then the handler can extract it from there.

A

I'm not sure I would like to do dictionaries in general because they also don't seem to be super cheap right, I.

E

Mean we can make some optimizations to make them a little less Ella Katie, but there would be an expense. I mean.

A

We could just say that we have an abstraction right, some sort of type that everybody derives from, and you know this can any public API that effectively allows you to inspect keys and get Vegas out of it. The underlying thing doesn't actually have to be dictionary, but it could be some smart thing that doesn't locate a lot of stuff, so we can probably still solve that and I. Think, generally speaking, people don't like dictionaries as you've said, it's things to generics, it's not very pretty. Usually, so you probably want to hide the dictionary anyways.

A

Yeah I think the design would scale right here. I mean I can easily see this being also very composable.

E

So when you have these special handlers, it it's all very handler specific functionality. If you have this pseudo dictionary type, let's say and I pass in a you know: xamarin Android handler option into a web assembly handler what what would the behavior be.

C

Okay, so ignoring it is one thing: is it possible? We could make it throw because if the HTTP client that you're using internally constructs a web assemblage to be message, then, when the extension message extension method tries to do some Android specific stuff, it will try to downcast the message to an android message in it. The cast will fail, so it will just throw.

A

Yeah, the polymer I think to the earlier point is that my concern of doing it is literally deriving from the messages is that then it can't compose right in a given point in time. You can only have one of them and that's the problem of cars, libraries, where class leverage themselves construct the message already for you right. Then you have to change the mechanics but which is the nice thing of this.

A

You know Advanced Options concept, everything everybody just takes these Advanced Options that effectively just you know, set on the on the underlying message and then the handler just has to extract known P is effectively right and then you could even have a concept and say certain options are required. So if the hunter does know about them, the handler is supposed to throw- or you could just say, something's are just optional things that are nice to have, but the underlying handler knows what to do with it. Great. If it doesn't, then nothing bad happens. Well,.

C

I'm not sure that it's completely the case that this worm compose. So when in any given situation, you have one specific handler involved, so you've either got the webassembly one or you've got an android one aware about this. If there's an actual underlying technology and that technology knows what features it supports. So if it is cut able to define a concrete type that that knows about those capabilities, then you can have as many interfaces on that as you want to represent all the different kinds of extension methods that are applicable to it.

C

So you can have the I accept fetch options, interface and I accept Android options, interface and then only you know when you try and do the casts to the relevant interface type will see whether or not your handler supports this kind of option, so I would implement those interfaces.

C

Whoever implements the HTTP request message so.

E

Now there are the a like had lured, create options, method, create options; builder method that would I guess, throw if you add an incompatible option.

C

Well, I would imagine MSE an extension method called something like set fetch options or even more specifically set integrity or something like that, and the implementation of that would take the HTTP request message and it would try to catch it. Kirsta to an I fetch HTTP, request message or something like that, so that it can start setting some strongly typed properties on there and if that caste doesn't work, then we've. We realized that this type of HTTP request message doesn't support those types of options.

A

I'm still struggling with like visualizing how this composes I mean like so imagine, you have a library that does all right and the library basically does the thing already for you where it constructs. You know HP client and it constructs, and you know, messages whatever right and then you know the library you also allowed to possibly on Hunter as the escape hatch right. So you know you mention you try to use this thing and it wasn't right.

A

So you were basically passing that assembly HTTP handler to this thing, and but now this library has to be aware of every assembly in the sense that it has to be able to accept represented specific options. Somehow all right.

C

It's the library responsible for creating the request, messages or is the handler responsible for and those messages.

E

A

Mean okay, so today that's alive because literally people just knew them up right I mean you could introduce the factory method sure, but that's alright! Well, if that's the case.

C

E

Could pass the options dictionary to the library, and we can say you know if you have a library that might have some, you know handler specific options that you can set just pass this parameter in and we will use it that sort of thing. Yeah bedrock has a very similar concept of exposing features on on things. For you know, this dictionary type.

C

Okay, well, based on the scenario you've just described, then I agree. The concrete types are probably not very, not good moves, but the same kind of approach using a loosely type properties bag does still seem to be viable.

A

Yeah I wonder like I think it seems like the conceptual model that we all seem to like. Is this news property back right? Where message just has a bunch of data that they handle knows how to process right. We just don't like the user experience right, we're moving like strongly-typed API, it's effectively right or you know, dictionaries of key video where videos object, but maybe that's the only thing we have to fix. Maybe that's the only thing we have to try to make this more strongly type. Yeah.

E

I've been playing with an API almost exactly that for networking and I managed to make it strongly typed and a little discoverable to see if I can find a link to that.

E

Links in the chat.

E

It takes inspiration from dependency properties in WPF as a way of handlers, kind of exposing what what properties they support and then it has a strongly typed in this case just to try get, but there would obviously have to be a set option.

E

So if you look at the after portion is what I, what I'm talking about.

A

So when you co see.

A

So how would that work there with the connection property key, live that.

E

Would live on the web assembly handler.

E

That way, you can say properties, dot, ad webassembly, handler dot integrity, blah blah blah.

A

I see, but so that just what is the key, so he.

E

A

Name basically so.

E

The key is that connection property key type, and it is strongly typed, so you're not passing in just object. Oh I.

C

See so y'all try get as generically typed on that? Yes,.

A

Thanks, okay, that makes sense yeah.

A

And presumably you would you know, the properties collection itself would live on the message.

B

Yes, it's already there, so just reuse, the one! That's there. Imagine oh.

A

E

Do it skied on string, I, think yep yeah string object.

C

Yeah but we could have a set options of tea method that deals with populating that properties back bit in a slightly more strongly tight. Now.

A

A

Yeah, that would not be entirely horrible.

A

E

Not be discoverable by Beijing, but we can try to make them a little easier.

C

I think this is good, but it doesn't address the question of how this then composes with all the various extension methods on httpclient and convenience methods and so surely saying that's not really a solvable problem. Oh oh yeah.

E

We need some sort of property bag type to be able to pass in, so that when various libraries are creating messages, they could just use that property bag and set it right.

A

Basically I mean it's: a general downside of using I mean it's good unfortunate, that vanish being message. It's typed, I dictionary off string object as opposed to some costs, recharge the device. So my dictionary of string object because then you know you don't want to have an API to take an ID dictionary of string, comma object, but ideally you would have some sort of options type that because it is an implementation and then we could define them.

A

You know basically merge semantics on the type people can't pass the thing in and then effect of the implementation would just say message: the properties don't merge whatever you are you passed in right and then through this way it would compose quite nicely. So you could.

H

A

That right, because you can still define this type and just say on the messages- this happens to be a dictionary object, but we could have an options, type that.

A

Would define that you could use also to define extension methods over all right, I made it a bit more nice to say so. One benefit.

E

Of having a new property back type would be, you could potentially reuse that property bag across multiple requests, whereas with the current string options dictionary, you have to set it for every request and whatever allocations that would create.

A

Well, I mean I mean depends how you want to do this right. If you want to I mean we could do one or two things you could just use the options type to just make it, so you can pass them in and then still just effectively merge this guy with the underlying properties collection on the message, in which case you have to them the same cost. It just happens for you, rather than you having to write the code by yourself, or we could just say it's good.

A

We just introduced this concept on the message, and then you have a bit smarter about how we probably merge them, but I'm not sure we need that yet, because below, can you actually allocate too much or.

C

Not yeah I wouldn't be concerned about a handful of allocations, because people only do this when they're about to issue an HTTP request- and you know, that's actual network traffic- that's going to do probably you know thousands of allocations anyway,.

E

Yeah I'm not too worried about the webassembly scenario, but allocations are something that kind of hurts us in other scenarios. Right now, if we were making sort of a generic property bag, type I would ideally prefer to have zero allocations or as minimal as we can get.

A

All these amortize there all right, I think it's okay, there's a six! Yes, you just don't want to pay it pretty clear.

A

Yes, I think so we're kind of out of time so like I, would say corals design. With this you know, typed property of T seems like a workable starting point to make the thing not just a stupid, T beg your back and we can extend on that and saying. Okay, maybe we should have an opportunist type that we can actually reuse across different handlers and then the handlers themselves are just basically responsible for fishing, these properties out of the request and then do whatever they need to do.

A

I think we serve to decide what we want to do when the Hendra doesn't know what the property means. We could decide that it's rose. We could decide that it just logs. If you have a logger configure I mean I, don't know enough to make a decision here, since that throwing often has the problem that it might be. You basic all of your way to make things not work that could have worked, but that makes sense because it kinda depends on what the property is for right. If it's super essential.

A

Well then it probably you know the it's not that it's a hidden problem, that the user probably can't connect to the server then, and then they realize that they have to construct the right-hand right.

A

C

um So yeah we are coming without for now time and but but on the blazer side. We kind of have to answer this question fairly soon, because at the moment, when I was doing a bunch of work to implement some of this stuff, and if we were ultimately going to be doing the property bag thing, then we wouldn't need all of the refere sembly stuff that Pronovias currently doing.

C

So. How can we try and close on this bike within a matter of days.

A

So I mean I would first say like I. Would I don't know who's in the hope for this, but it would be good if you know pronoun or somebody on RT, and that kora can help you, which is getting this into a shape. Everything like it's a it's a property.

A

If you can somehow merge with the message, rather than demanding that you typed about some fun message, it still seems you need a bit assembly. It should be healthier, though I think that one won't go away right and it also seems we probably want the enums or whatever other types you actually have, because nobody wants to deal with object. Right so seems the work is largely similar. It just means that their actual plumbing is slightly different.

A

G

It does sound like if we're going with the the property bag approach, that, oh, that you just need to make that work in the non-public handler implementation that we use for blazer, and we don't you don't- need any API review before build like we could make the experience better, but we don't need it now.

A

So you're saying that, basically, we don't have to construct it up at some DHCP handler, because there already is a hidden one that we automatically create based on where the people are running and so, instead of F assembly, we construct the correct one that actually can't talk to the fetch API and that one can just fetch the right data from the from the message anyway. So basically wallet, but this disappear from the handler. You don't need type. Is that what you're saying yeah, yeah? Okay, then I'm, not sure you?

A

What do you mean by no API with you before build because I mean they wanna ship stable, but I build right? Well,.

G

Like it's, we could make something with a like if the, if the only thing that we can ship at first is there, you set these magic strings and then you know if we don't work out the Builder slash, you know intellisense based experience before then we have a working implementation. We can just make the user experience better. We're not blocking functionality is my point sure, there's nothing time-critical, there's just time-sensitive.

G

E

If we do have some sort of new property bag type and it needs to integrate with request message, this won't work without dotnet five.

A

That's a good point, maybe two hundred three one yeah.

G

But if all we said in the interfaces, its I guess yeah, if we're passing a new thing into HTTP client, post async stuff, it has now comma extra options. Then we'd have needed to define that method, but again that that would mostly be a experience improvement for later. You know, as in five yeah.

E

It is the goal for build to ship some out of Bend package that works on dotnet 31. Yes,.

B

So please, a projects target net standard do one that's even more problematic.

E

A

And for my point of view, there they're not more less problematic because both are fixed at this point right so like let's set up two one, might a few api's and make work through one has before frozen, so that so either way we basically have to build stuff. On top I mean it seems, like you know, the the the strongly type properties the core suggest would be workable. The base it just means you would have to have a type where these properties can live on.

A

um I, don't have a strong opinion where there is, it could be just you know a type called that assembly options or something right, and then it's a steady class who, just you know, properties effectively on them, and then it would just basically say you know, message: dot properties, dot said effectively right and.

C

So who implements this set thing, it is not gonna become a new extension method in the short term, since we can't add any real numbers. Yeah.

E

C

E

Could fit this into the current httpclient is if that property bag, or these new property types went into the existing properties. Yeah.

C

I I agree, in which case I'm not sure what benefit there is in having this special we typed way of access in the dictionary if you've got extension methods anyway. Why wouldn't you just have HTTP request message: dot set fetch options and the new passive fetch options instanced into it, and it deals with merging that into the property bag. Yeah.

E

C

I think that's fine.

E

It breaks the composability argument that we've been throwing around, though I.

C

Don't understand why it breaks anymore, like ultimately, the underlying storage is a property bag. In both cases, isn't it.

E

Yes, but we're talking about being able to pass this property bag to some library that constructs its own message and reusing.

C

The existing properties.

E

For that that doesn't work all.

C

Right I see yeah yeah.

A

I mean the question is: what did the extension that is defined over right there? You probably don't want to define them or a dictionary of string, comma object, but we want to define them over message. Oh this.

E

A

Type right, yep, and so it's a bit said if we define them not over the message, because they'd only have to define them over the option card, but that also doesn't seem to be the end of the world.

C

Okay, well, sorry, I! Guess we can't go on forever. Shall we try and come up with a written proposal that describes this sort of thing and then try and do another review, maybe start next week or something yeah.

A

I mean we could even do this week right I mean I originally set it up for Friday, but then nothing can have asked me to move it earlier. We could. We could try to do another round tomorrow. I know that tomorrow, most of you are busy to do some security review for Blazer. Okay, I mean we could do it sometime later today, let's or later tomorrow or Friday Friday early morning by the ones we wanted to do it this week.

A

I think at this point most it depends on how fast somebody can come welcome service to learn proposal for the for the new system. When are you going to do that? Yep cool then? Just let me know when you think it will be ready and then ever just setting up some another meaning for that all.

B

A

Thanks everyone guys this is. This is great cool thanks, mom.

E