Yeah, that's that's great. That's great. So now we will have our next speaker. So we have Andrews So I hope I pronounced correctly Andrews, is that how I pronounce your name or did I put your name? Sorry about that Andreas, yes. Okay. So Yeah, I see that you're going to talk about hot beach So it's it's gonna be something different, right? It's like it'll be very interesting like, you know Python usually people won't release that to a human body. So I think that'll be a very interesting talk. So Yes, that's the slice there and I'll let you take us away then Okay My name is Andrea slow salmon and today I'm going to present to you a topic that is very close to my heart and probably yours I graduated from veterinary school in 2018 so I am a licensed veterinarian in Germany, but I have mostly worked as a full-stack developer currently I am employed at the company doing full-stack work with mostly react and dot-net and My talk is going to be about hot beads and how to detect them Your heart is the organ that is pumping blood through your body and it does so at a certain rate and There are quite a few ways to observe what the heart is doing how well it is doing it and even to detect potential problems this talk is going to cover some basics about the physiology different kinds of heart beat sensors and especially electrocardiography or ECG Hey Andrea, sorry to interrupt, but I think that your slice is not really working for the stream. So maybe we have to Do you mind re-sharing again? So maybe hopefully we will fix that. I think it's I Can go I didn't oh now. Oh, okay. Now. It's okay. Sorry about that. I thought it's not working. That's fine. Okay, so Yeah and Yeah, this talk is going to be about different kinds of heart sensors about physiology and I am going to show you how to build a relatively simple Arduino based ECG device And then I'm going to introduce you a bit to ECG analysis with a bit of data science and machine on it So observing the heart with computers There are several basic modalities to observe and we may an art with a computer One would be acoustic as phonocardiography Which is how the smart people call it and This is basically like a stethoscope or you put your user Microphone and you're mostly interested in lower frequencies There are even digital status copes out there right now, but they aren't very Common because they are probably expensive and if you carry them around a lot then they break Anyway Then there are mechanical sensors, which is called seismocardiography and That is relatively recent because they now have these little M E M S Selerometers that you could also attach to attach to an Arduino or something and you can attach the sensor to the clavicle and then measure the Waves there's the information You can measure vibrations coming from the heart and these this information would be similar a bit to Phonocardiography, but even lower frequencies and it could also be quite useful Optical sensors Many of you have seen those often they get attached to the finger and They shine a light through the tissue and by reflecting or transmission by measuring the reflection or transmission of that light you can tell the heartbeat Because the blood is pumping through the tissue and then it changes its transmission or reflection or whatever and there's also a need to trick to tell how oxygenated the blood is and That's not going to be part of this talk the electrocardiographic Modality is probably the walk-offs of cardiology or has been for a long time and That is about measuring electrical potential difference differences, which I'm going to talk more about later then there's ultrasound which has somewhat replaced ECG and some applications and it is a very real time way of looking at the heart and You can tell a lot about both functioning and so on Then they are lately have been more and more research into using MI and CT But that of course is out of the range of any normal hacker This is from Wikipedia a Video of ultrasound recording in 4d 4d because it's a 3d presentation and the fourth dimension is time and you can actually watch in real time how All the moving parts are moving and you can even tell when something is flowing where it shouldn't and that's why this has been very Very much used for everyday cardiology Also, these devices can cost cost a few hundred thousand dollars right now the most advanced Devices which is more than an entry level computer tomograph or something Now there's also real-time MRI which is also relatively recent and you can Give even more information or get more information because it's magnetic resonance imaging and it looks rather cool Now I'm going to tell you a bit about how this actually works So we need to understand that the heart is Pump and the mammalian heart has four chambers to atria and two ventricles the atria are small the smaller ones and ventricles are the bigger ones and Left ventricle is pumping blood through the main body circuit and the right ventricle is pumping back through the lung circuit Vane's feet say atria and Coming from the body circuit for the right atrium and the lung circuit for the left atrium The atrium is a kind of a priming pump So before the larger ventricles contract the small ventricles pump the blood into the bigger ventricles and for optimal function and these smaller atria have to Contract first followed by a contraction of the ventricles and several things can go wrong with all of that and All of these problems Could lead to reduce cardiac output a little bit about heart cells physiology, how would that all of that work on maybe also an electrical level the heart muscle cells are very specialized kind of muscle cell they Know how to contract a when to contract mostly because the neighbors are Contracted which they sense by an electrical impulse Each cell forwards its excitation to the next so this actually works a lot like laula wave Well, like in the stadium where somebody stands up then the next man stands up and so on and it's much of the same or the same principle in a In the heart excitation you basically basically have a traveling wave of heart cells getting excited and when they are When they just contracted they go into a sort of a dormant phase where they came for a few Well milliseconds for a certain period they can't Get excited again and When we are doing electrocardiography We are listening to the waves of electrical potential to generate it by the excitation of these cells Now what is ACG anyway? As I said There's this traveling wave of excitation and we need to We need to measure the electrical potential difference between two points Mostly or most done at least that would be the left arm and the right arm And then we have a reference electrode somewhere else and There are standardized ways of doing this which I'm not going into right now Yeah, so actually measure this you would need in differential amplifier and I actually don't understand this diagram I'm not an electrical engineer and anyway, this is This would be from Wikipedia and shows how differential amplifier might work and Components and these components are relatively tricky to set up for for a beginner electronics hobbyist and That's then that's a good thing that we have these 80 H to 33 88,000 88,000 232 ECG sensor boards This is a small little chip on this breakout board with a lot of small and tiny components in between The good thing about this board is it just takes one power supply of Ground and 3.3 volts and then it gives you an output an analog voltage signal From zero to 3.3 volts It also has lead-off detection with the LO plus and minus pins, which I'm not going to go into and the SDN pin will Is this is a basic heartbeat detector? Which you could also listen to and then The This heart-shaped outline surrounds an energy that is also beating through your heart if it works The headphone jack is for electrode connection the some of these boards come with an electrode cable or three electrode cables that Headphone jack and or headphone Connector and then you can connect these relatively simply but People say that this doesn't work that way and I also prefer to solder electrodes to the To the three connections at the Top edge here and they also never labeled for right arm left arm and Right foot I think Right leg Now if you have amplified the signal now, you need to read it You need to convert the analog signal to something digital which is a job of analog digital converters and Arduino boards often have an ADC built-in, but it also has problems and these I squared C devices can convert Analog signals at 16 bit versus 12 bit and 860 samples versus 3000 Samples I went with the right one because I wanted to have 1000 sounds per second another Secret about these boards at least The cheaper ones is that if you feed them 3.3 volts instead of 5 volts and They are slower And you just need to know that If you don't know I squared C, it's basically and some people will hate this energy I squared C is a bit like USB for microcontrollers. It's It's a bus for data connection or data transference between the microprocessor and some Periphery devices and it only needs two connections to the pins, which is also quite nice Then I chose the ESP 32 as as a controller board for this For this project and I chose one with an LED and a battery You can put an lithium-ion battery in there, which is good because when you deal with high amplifications and signals and the power line can Inject transference even over a USB Connection and this makes it a bit easier This these particular devices want to be called We most low in 32 That's not really documented anywhere, but if you call them anything else and the IDE won't upload to to this board All is be 32 dual course with Have to they have two CPUs and They are running at 240 megahertz. That is quite nice because they can they have quite a bit of power They can also be programmed with micro-python or cycle-circuit Python. I Decided to use C++ with the Arduino framework Because I needed better Better scheduling and real-time performance For what I'm doing And as you know when C++ is your hammer everything else starts to look like a thumb That was from the pie jobs collection by the way So the general plan is collect samples from I squared C ADC Drive that loop through a timer interrupt Put samples into a buffer That regular intervals send the field buffer off by Wi-Fi I'm using TCP RP now, but I could also use UDP which has advantages and disadvantages and That would I would like to Make a joke about UDP right now, but you probably wouldn't get it now The big biggest problem here is that sending takes at least four milliseconds and if you do it naively then You have a gap of four milliseconds in your one millisecond spaced samples So what you need to do is multitask in with these two cores on the ESP32 the ESP32 can run free IPHOS and that is a real-time operating system The correct way to implement it and I have discovered a few not so correct ways Is to do the sample collection on core one So there I filled the buffer with the samples I collect Then I Then I need another task on core zero which sends the buffers at regular intervals Now what you need to know about TCP IP and Wi-Fi is They need a lot of housekeeping and the microprocessor has to spend some attention on that So your task must not block core zero at As all too long or otherwise nothing happens with your Wi-Fi You have to call Vtask delay and Vtask delay until and if you've ever worked with SMH IO It's basically the same Same principle your task monopolizes its core or threat and Nothing else can happen until you yield Yeah, I am going to try and Switch to my live demonstration Now the problem is it doesn't really work completely. I can I have gotten ECG signal which is set up before but Unfortunately, the connections are not very reliable and I might have some Ideas how to improve that in the future, but right now it doesn't work, but basically it's It sends samples at 1000 frames or 1000 samples at a second and I have the first fast API server running Collecting the samples or receiving them and then putting them out to this okay react app I wrote integration of okay with the X that works over web circuits Here we get some signals, but that's almost Yeah, I've gotten signals that actually look like ECG, but this is really not it Better stops the presentation other you more right there But that's what what you get when you try Light things phone button now we're back to the presentation and Let's do some data science. I promised data science. You can go to Physio net org and download data Did most of the records in BFTB format most of the records are in BFTB like WFTB format and There are several databases collections of samples sometimes they are labeled with all sorts of things and That's a few years ago part of physiology also There are not just ECG Recordings also Of course, there's a Python that your module for that Going to go into that much you can of course plot the data This is ECG data most of the time the recordings are with two leads which means two dimensional signal and Yeah, that's Just about all there is to it What you can also do is to conclude 2D histograms I using data data shader Here from pie data and this is just a 2D histogram of the two lines of the two leads moving together and then you get a picture of how we How the heart all the electrical processes are traveling or how the Traveling wave is moving because Basically with two Two leads you can Intersect the three-dimensional movement of this traveling wave and This shows you how Predictable the heart is beating or how predictable And the electrical connections are and it can look a bit more strange like these recordings from the MIT Bih arrhythmia database and When you see multiple loops, then you cannot already tell that there are hard actions of different shapes and Also in the middle, there's a lot of uncertainty and probably fibrillation going on in the HVA and on the right hand side, there are multiple forms of ECG actions but which are sometimes but Only the one in the middle going downwards is probably the prominent one and the other two are more rare Yeah, it's a nice way of visualizing those Another way is you can use data shader to To visualize one D Only one beat and the way you do it is you first have to detect or know where these Where the big spike is which is the arse pipe of the QIS complex And I'm going not going to go too much into it That maybe for a later talk how to analyze is more but this is Just Basically, you need to know where the arse bike is and then you lay you put all the hard actions over each other and Computer histograms for example data shader and then you get this picture What's remarkable is that this electrical action is not very random but relatively deterministic It's often so that when you have Disease conditions then it would show up as more random We would see more chaos in there or more other thicker lines But when the lines are relatively Thin, then you know that this is a very predictable process and Now I promised you some machine learning also and My main project in machine learning with ECG currently is trying to detect beats normally There are a lot of the beats Detection algorithms most of them relatively simple some more complicated and You might think you could just look for the big spike and be done but unfortunately, not all of not all ECG signals are this nice and So you have to calibrate stuff and Sheen hyperparameters and so on and I tried to use I'm trying to use convolutional neural network with Keras and to Make a more robust beach detector that works with almost anything and In this picture, I have Blue line, which is the original ECG data and the blue dots are the manually manually marked Beach markings manually edited from the database and The orange line is the output of the neural network which says with what confidence there is Heartbeat and this works relatively nicely. This Is a slightly more difficult ECG diagram to analyze for a computer because there is this in the middle base a jump in the voltage level and The less sophisticated I wasn't might just say there's another beat because we are having a spike but at least this algorithm doesn't do that and Can go even crazier like this we have multi-form Heart actions The shapes are different from different heart actions from one heart actually to another and on the right side we have probably motion artifacts and smaller Qis heartbeat looking things and the algorithm still picks that up and This congruent receive with with the manual demarcation and Then I also tried it across the species and this is the buff diagram it's about dogs and The is the one below is for the mouse and They are also from fission edge. They have a zoo database with a few species as we see the algorithm still detects the beats and But It's not that difficult of a task because all the hearts of the mammalian genus or all of the hearts of the mammalian mammalian Species will basically produce the same ECG just different Difference of size if you have a mouse that Little animal like a mouse will mostly have a higher heart rate and This these heart action shapes will be smaller and By just scaling the signal a little the neural network Detects everything just fine now If I ever give another talk like this again, for example heart beats for heckas, too What might be coming next is for example a more reliable hardware Because hardware is Hardware is hard and biology is even harder I Intend to use the only only D screen similarly or simultaneously to the measurements the problem is currently that They both want to be on an ice-cream at sea bus and I still have trouble Figuring that out. I might have a way to make this work But well, yeah, I'd also like to try out mechanical and optical sensors Which would be that we would add another dimension to the data And it should also be relatively easy it would also be nice to show the CNN V detection in real time, which is possible because it's quite fast and the neural network isn't that complicated and I Probably would also tell more about easy gene analysis now that was all for now and I'd like to thank you for listening and session chair for introducing me and Yeah, well, then we may have time for a few questions Yeah, so that's great. That's really good and it's very interesting as well. So we do have one question So let me put that on screen Have you played around with the cardio? Bandage, actually, I know nothing about that but from the CCs come 2019 by any chance There was some interesting easy to experiment with that one as well. Have you heard about that or no? No Yeah, so Yeah But yeah, like all I know about easy G because like I know that I well I'm a Apple fan So I use the Apple watch and then so there's this easy G function that you can measure your heartbeat and stuff Right, so that's the only thing I know Do you think it is accurate? And if I measure it, can I use my data to do some analysis? Yeah, probably I Don't know if you can how you can access it, but I think you can just Access the data. It might even be the same shit like I showed you on this breakout board something similar and I mean you there's all this there's all this regulation about what an easy G should be or but but really I mean as long as you have valid easy G data or you see the shapes are coming out Then it should be usable for some kind of Information in clinical information in some part, but you would have to be careful with that always Yeah, so I think I've also put a disclaimer that like, you know, don't rely on it a hundred percent because you know They don't want to be have responsibility if you know, you have problems and then later, you know, sue them or something So that's another question if I got it, right She used a C++ on the ESP 32 then like with this have been possible with Python In terms of performance, I haven't tried But I haven't I hadn't tried I don't think it is that possible I'm not sure because the basic thing is I want to have one thousand samples a second and Do some networking in between with the other core and that It's important to get one sample every millisecond at the right at the right or Consistent interval and that's harder when you do garbage collection and whatever else the Python interpreter does So I haven't tried at a lower resolution you might Be fine, and it's usually most tutorials and YouTube videos about ESP 32 and Measuring stuff IOT wise Use much lower sample frequencies. And so I had to more or less find figure out myself How to actually do this in a real time way Yeah, I think it's amazing that like you can do so much stuff with open source tools and Python But do you think it's a risk if like people can just do like, you know, analyze their own medical data That you know with a with a small gadget like Apple watch or anything then you can collect medical data From yourself or from a family then people can analyze it themselves And do you think it's a danger that you know people rely on it too much and didn't get them, you know Professional help or things like that. What what's your thought about that? It's extremely difficult right now to do that And at all and I mean the apps will have their limitations always but There's Well, I'd say the applications will always tell you stuff or information about ECG maybe and they won't do the diagnosis for you And you would have to put the diagnosis Diagnosis into context of your other health parameters and then do something about it. So for basic basic prescreening it would maybe enough With artificial intelligence and so on because you don't Expect a very hard a very high rate of disease in pre-screening or screening people and I Don't I don't see a lot of danger You really to do ECG analysis You have to know a lot and then you sort of know what you know and what you don't know and Of course, you can't use anything what I told you for Personal medical advice or something, but I think that's pretty clear that This doesn't Replace any doctors Yeah, that's absolutely true. So I think yeah, of course if you know people if you have you know Suspect that you have health problem, please get you know professional help I mean you could get some you know have some fun project like this You know, but you know don't rely on the small gadgets because you know, I think all of them would tell you that Don't rely on them Yeah, thank you so much Andrea's and this is really really interesting. I think I know that all the other pictures and demos are great So I think now we are going to a coffee break


Teachers create strategies chefs create recipes and scientists they create formulas and my guy Kevin He is gonna give us the formula for a Super Bowl win for the Baltimore Ravens He said ain't graven since we do not have a number one wide receiver and it's too late to get one this season Here is the formula for a Super Bowl run Offense short passes and multiple receiver and running backs hands Let the other team's defenses get tired Too tired to tackle the players for the first half more under center play actions and runs. Yes. Yes. Yes Second half run it down the other team's throats use Mike Davis if you don't have gusts of jk shaking my head Defense continue to get better with qb pressure and replace away with a job or lol What do you think you he's been getting on the way all season? I mean a lot of people have though, but um I don't know what it's been man. He just I don't know and I know some of you. Oh, well, he's been getting held a lot.  He ain't even been playing every game Um, so I'm not sure exactly what it is with a doubt for your way I haven't sat there and just been laser focused on him and been watching this every single move or whatnot But I'm not sure exactly what it is with him. What's going on? But back to the part about the offense the short passes man and having the multiple receivers on the field I agree the up tempo passing game the short quick passing game It helps a lot. It helps get LeMond more of a rhythm It helps get the receivers in more of a rhythm It keeps the offense moving and keeps it going and then it can't wear out those defenses And then in the second half like of course you want to use your running game in the first half too But really in the second half you want to be able to use that thing so you can close it out You can close it out It's been a theme with the Ravens, especially since Gus Edwards had been back I know he obviously missed the game against the Saints But for the three games in the road that the Ravens won in the second half that run game Has been able to close it out and it's helped out the Ravens so much in them With the run game if your running game is going good that helps to play action game Especially to play action game under center Because under center the play action game is more deadly in my opinion than in a pistol or in the shotgun or what not So those are some You you got a good strategy there my friend. You got a really good one So we appreciate you being the scientist, but he wasn't done yet. He said one more thing Shout out to geno stone. He's getting better and better each week We're definitely not keeping Chuck Clark next season. No knock on Chuck Clark It's actually speaking on how great geno stone is playing um And I I think Kyle Hamilton too like I mean, it's only a matter of time It's only a matter of time like this this year. They like hey chuck.  You know, uh, it ain't happening Um, so we'll see next year though But he said uh, the Ravens remaining schedule should make their team prepared For the playoffs and the bills don't have a win in their division yet. Ooh, there's something right there um, but yeah, I mean Ravens previous schedule The schedule they done been through um that they were battle tested for sure in that one. Um, and it's crazy to The teams with the winning records Ravens lost to them Um, the teams that they failed when they when they faced those teams and they had a winning record They lost it like they they lost to the bills. They lost to the dolphins and they lost to the giants So There's something to think about. I know the bingles have a winning record now But I don't think when the Ravens played and they had a winning record But the the the teams with the best records that the Ravens played they lost to all of them. So Yeah, they they they got some work to do. Uh in the last part of his question He said they are listening Run more roll out play action quick hitches and why don't they use mike davis in this game? Get the saints defense tied and run the ball down their throat also give tylen Wallace a quick hitch See what your receivers can do. Yeah tylen Wallace. He was inactive for that game against the uh The saints uh mike davis Mike davis says they don't use him in the run game at all Ever since that dolphins game they said dope.  He you know, he's not getting the ball handed off to him Like on the saints game, they gave him a pass. Lamar like ended up throwing it off to him and in a little pass But He is not to run the ball. It's a no-no running the ball with mike davis ravens are They like they they done with mike davis in the run game and that's been Clear as day, but as far as more rollouts. Yeah, they've been doing that more They've been doing that more, which is a good thing. You can do it even more play action. We just talked about that uh quick hitches and uh Yeah, that's that's exactly what they did get the saints defense tied and run the ball down their throat That's exactly what they did in the second half to finish the game Yeah, this feels like a dream Keep it clean welcome to another episode of questions from subs and to keep us going next question came from my guy golden rano Would jk except the third we did it again in graven. Am I happy to go into the buy week at six and three? Absolutely. Do I feel confident that after nine weeks of play that the past offense is gelling and improving to the level It needs to be for a championship run. Not exactly. How about you? No, no and and I think um With a lot of the receiver talking all that the passing game talk, um I don't think many people's uh Their biggest fear Concern worry was for the regular season No, it's come play off time But for me, I can only speak for myself for me My thing that I was saying with the ravens passing game It's it's a dangerous type of passing game because uh since the volume is so low everything got to be on point And we've been talking about everything got to be on point if one thing is messed up. Oh, wow, it looks really bad It it can look really bad if one thing is messed up if one part of it slips up makes a mistake miss what? It everything is emphasized that much because the volume is is super super low um, so with that when you go into the playoffs in the playoffs teams they will sell out To do everything to take away whatever your strongest, uh option it whatever your strongest Characteristic of your team is For the ravens on offense. It's the run game So this is why uh for me This is part of one of the biggest reasons why I wanted the ravens to really invest in why receiver like that Because of playoff time because okay regular season. They already show a regular season. They can get by We know a regular season. LaMars healthy. They'll be a okay But it's playoffs. That's when you need you definitely need more other guys to make those plays Guys got to step up But this is also why I wanted the volume to improve and the philosophy to really change because of playoff time Because playoffs are like regular season. This is nice six and three nights with ravens sitting right now nice But playoff time is is where the biggest concern is for me But anyway, he said uh, would you agree that timing and synchronizing must be improved during the buy week? Oh, yeah, for sure for sure Um Timing I know where la mar. He's been missing some stuff. He's been missing some throws And some simple throws too. Now, uh, like last night with the in the saints game. Um, some of the throws he missed Look at where they came after It's like this guy He uh, he had to escape like 50 saints defenders Uh, and then after he finally escaped and then he made the throw and He threw so he threw one behind the josh oliver threw another one behind the margis robinson um Was there another one too? What was that? Oh, no, he overthrew one to likely and I think those those were the only three that were just a little that Yeah, those are only three where he just like Missed him like just straight up missed. Um, but he said how do you feel about the ability to make big plays down the field? I don't know. We ain't been seeing big plays from the ravens down the field We just We ain't been seeing them We ain't been seeing them They've been taking a few shots here and there, but We just ain't been seeing it. They they've been more of a grinded out type of offense um And hopefully with the shan jackson if them hammies could be right like, uh In devin do well not really doing they maybe but um Uh, the big plays down the field is just it ain't been a part of his offense Not recently at least it's They've been missing big time. Um, that could help a lot that could add another element to the offense Uh, it's up to lemar. It's up to g rolls up to the receivers. Um But it's just they just haven't been there But he said is a one-dimensional offense run dominant easier to defend Or does the element of the unknown confuse defenses keep them on their heels tie them out and weigh them down So I see what you did there That was like one of them questions where you set it up to where you we all know the answer Well, you just wanted to get that point across. I appreciate that. He said my original my, uh, original intended question Actually pertains to the running back room. Uh, as you so accurately stated last week Gus Edwards is without question the team's top running back and that fact is quite evident when the bus puts his cleats on the field Uh, he's a true game changer But with a dependable capable and effective king and drake backing him up Is jk dobbing spot on the depth chart as a starting running back in jeopardy Would dobbins demand a trade if dropped to rb 3 now when it's third season He'll only have next season to prove his value. Is it me or does edc have a propensity to draft often injured players Oh um Wow that just An awful lot of his top guys. That's how it's been working out like, um um But uh with jk as far as him If he was dropped to number three running back, I mean it's all about going with the hot of hand So when jk does come back because you still have justice heal there too. You have drake. You have gusts, obviously gusts so he gusts should be the number one back but um Ravens a lot of times they don't really have a number one back But one thing they've been doing this year, which has been so much better. Thank you so much. Keep it up, please They've been riding with the hot hand at running back for the most part They've been riding with the hot hand at running back and I just appreciate that so much Because it makes such a big difference and they need to keep it up So it would I don't even think it would be that jk would be demoted to rb3 It would just all depend on who got the hot hand at that time Why the hate next question came from my guy david. Say what's up in graven. Hope the fam is straight Oh, yeah, we're doing good. Appreciate you. Why the hate? Why did the flock turn on project pat? What did he do if you asked me it's another sign of us getting spoiled and not understanding the strength and the root Of our team are running the football pat ricard is one of our biggest weapons Why losing ricard in any sense fashion would potentially stall the offense. Hear me out. What if scenario coming? all right, so first the first question about pat ricard, uh The flock turning on project pat or whatnot. I don't even think it's necessarily people turning on project pat I think it's people. Um, just wondering about a lot of the situational football And just wondering why he's out there a lot more than say another receiver A lot of times and in situations Where it's clutch time. This could be a third down and long. It's like, all right Right, he was may add like two receivers out there sometimes even one receiver out there, but Pat ricard is always out there. So I think it's just the usage and we know that with pat ricard He's an extra offensive lineman.  Well The philosophy is going to be staying the same Because if it was changing then pat ricard would have been gone Um, so that was a big indication of that. Uh, but anyway, I think that's what it is just The a lot of times the situational use of pat ricard And sometimes it could just be looking at the numbers looking at the percent that he's out there on the field Versed a lot of other guys, especially when it comes to receivers Um, and the fact that the passing game has been what it has been But anyway, let's continue with your question. He said can the raven still win if they lose wide receiver one? Yes, they lose tight end one. Yes, they lose rb one. Yes. They lose rb two. Yes They lose tight end one and wide receiver one. Yes. They lose what wide receiver rb one and tight end one Yes, what about if they lose wide receiver one tight end one or rb one and rb two Yes, even crazier. Could the ravens be top of the division without wide receiver one Without wide receiver one rb one rb two Uh rb three left tackle and the entire defense. Yes Oh That's a confusing read right there, but let's keep going He said now does the ravens often still move the ball without full back one in any of those scenarios Nobody can fill in for pat if he lose pat Well, I think nick boyle. I think he would be able to be a little different But anyway, uh, he said uh lamar would get killed and the run lanes would shut Point is we can win without the pass. We are dead without the run and defense We all know we need to stick to our bread the run game and butter project pat We do need more offensive creativity But I feel like you can do more with the same offense than we do But the identity doesn't need to change Again Playoff time, man Playoff time is going to answer this question As far as the identity in my opinion the identity the philosophy all that Because uh that that's that's the biggest concern for me. Anyway, he said imagine if chubb ran behind record Imagine if henry ran behind record, uh, jonathan taylor, kenneth walker, damon pierce breeze hall joe mix and polis Zeke come on flock This isn't a shootout offense like y'all desperately wanted to be And it doesn't need to be our wide receivers are good enough For the eight targets, they'll get our offense is one of one and that's an advantage that travels Sorry for the long message. God bless Oh, that's see that that's where it gets tricky That's where it gets tricky and I think that's another part Of so many ravens fans frustration.  It don't be the same In the past game, that's when you really need to rely on a pass game. You need to have a pass game ready I'd say the run game still can't do its thing I mean, it hasn't done this thing in the playoffs, but you you need a pass game to be ready And we just haven't been next question came from my guy ronald. He said hope you and the fam are doing great We sure I hope you are too ronald.  No, they released him from the practice squad No, they they got the shan jackson and andy isabella, baby So what they need a young tall athletic wide receiver for next question came from my guy greg and be more He said require smith potential consequences I'm so happy that require smith is raving I think a wide receiver move might have been great too But it unfortunately didn't happen, but maybe edc did try. I don't know. However, probably Wouldn't have tried too much with any of the two notable guys I'm remembering on a deadline day anyways with chase claypool who was highly unlikely still is with a trade at a guy like Him to a division rival and calvin really who's a conditional trade and I don't think can play this here because of the betting I'm not sure on his whole punishment. So I'm not too upset that ravens didn't trade for those wide receivers at least I believe the ravens will try to sign both roquan smith and Lamar jackson to extensions or sign one and franchise tag the other if both get extensions It's going to be likely top three money contracts at both positions Maybe even top one for both and I want this but There will be a cost unless there's a team friendly deal or restructuring on contracts It's hard to see important guys like marcus peters calais cambo if he don't retire and maybe even ronnie stanley Oh and maybe even ronnie stanley marlin humphrey and mark andrews might have to be let go next year Or maybe the year after next for humphrey for humphrey and andrews. Yes cap room is probably overrated as teams always figure out ways around the cap but it still exists I mean, I wouldn't even worry about the year after right now, but Ronnie sanley ain't going nowhere next year marlin humphrey ain't going nowhere next year mark andrews ain't going nowhere next year Calais cambo he could retire marcus peters. I don't think he'll be back But them three mark marlin and ronnie. Yeah, they ain't going nowhere. But anyway, he said, um The cap still exists top linebacker cubie money will be a lot on the cap plus If I say likely continue to improve and look great for the money likely is a cheaper option over mark the next few seasons And that's why I mentioned mark andrews possibly going and mccarrie and fi lele might not be bad options They left tackle though. I love stanley. They are cheaper too Yeah, stanley stanley ain't going nowhere mark andrews ain't going nowhere. So yeah, you ain't got to worry about that He said ravens could find a way to not lose all those guys But we'll have to wait and see lj is definitely a type priority But for roquan is signing him worth it For who the team could lose for him to get an extension. I know this is long But I try to be sure the next time have a wonderful day Yeah, I think um I just yeah, I Mark andrews marlin humphrey writing those dudes they are as safe as you can possibly be um The the biggest person that i'm worried about right now losing uh, and this was even before roquan smith I would be lemaw the last question on this episode came from the art well He said ain't graven. Thank you for your commitment to keeping a clean healthy fun platform for all ravens fans and fans of football Watching you from the car to the porch to the den to the vacation holidays, man You really come such a long way with this Inspiring to all who watch a true pioneer. I appreciate you man. Thank you And thank you team keeping clean for being the best fan base ever It is truly a great feeling to know there's a place for us to talk football like this Before we begin, let's just take a moment to remember the great ravens teams of the past Though ones who won the ones who lost are most and least favorite moments And graven, I ask you to walk with me through this one. We're headed to the year 2006 We finished 13 and three first place in the afc Although we fell short of a lombardi the roster was as good as it gets that year McNair the helm derrick mason and clayton and heaping jamal lures with a loaded defense was arguably our best roster ever Over the next 12 years from 2006 the ravens attempted different approaches But none as evenly balanced effective or dominant including our 2012 Super Bowl year I feel as though edc is ozzy 2006 literally We ravens fans will like to think he's different and we'll bring a new philosophy. Nope. Uh, not. Yeah. No Yeah, the philosophy is the same It's the same but let's keep going. He said, uh, I asked you to walk with me to 2006 Because I want you to think of the resemblances of that roster to the to that of the last four years edc has gone through four Madden off seasons and has attempted his own version of 2006 each time The addition of road qualifiers seems to confirm the primary focus as follows. Number one power run Two tight and centric pass game three defense defense defense for special teams That's it. Yeah You got it. That's it. You're right You're right He said my question with why receiver being a fan favorite discussion as an area of weakness that and the premier teams of the nfl All having past heavy offenses. Is this still a winning formula? And what was the best roster in ravens history till next time? God bless appreciate that. That's a that's a fun question right there. Is this still a winning formula? Yes for the regular season It is for the regular season regular season ravens philosophy. Hey, it's fine. It's fine. But playoffs That's where it gets a little scary now. What was the best roster in ravens history? Oh I can't say 2019. I think I think 29 was the I'm sorry. I think 2019 It was the the the biggest overachieving roster Um, because I just that was crazy um 2021 They did a a good job of building the roster. Everybody got hurt. So that kind of mess everything up um 2011 2011-2012 they they had some nice little rosters there man. They had some nice little rosters on both sides of the bowl Um, because they had play I remember will this be get no ricky williams Yeah, the the ricky williams when he was on there. Yeah, 20 2011 was nice, man But yeah, 2012 was nice too because that's when they added jacoby jones, man So, I don't know that that's that's a that's a really good question. That's that's one that I would like really really I have to think about right ravens done. They they done had some rock They done had some real rough rosters, but they they done had some nice ones From time to time too. So that's that's a really tough question. But it was fun. Yeah, this feels like a dream The shot I did gravy


Choosing keywords and brainstorming synonyms. Now that you have done some planning and come up with a good research question, you want to think of some words and phrases that describe the information you need. These words and phrases are called keywords, or search terms, and they are what you will use as you search for information. You can think of the stage of the research process as translation. You are taking your research question and translating it into a language that will make sense to the search tool you are using. For example, if you are using a research database to search for information, your search will be more effective if you are using language in a way that the database understands. This sounds complicated, but it basically just takes a few simple steps. The first thing you want to do is look at your research question and identify the main ideas it contains. Then you want to pick out keywords that express these main ideas. Electric car, purchase, and Canada are the main ideas you want to learn about for this question, so these are a good starting point. What you don't want to do is just type in your whole question word for word. This is not the most effective way to search using library databases, or even the most effective way to search Google. After you've thought of your keywords, think about each of those main ideas and try to come up with other words that mean the same thing or express the same idea. Make a list of these words as you think of them. Another good place to help you think of these synonyms is your background research. Some synonyms for electric car might be low emissions vehicle, green vehicles, and hybrid car. Some synonyms for purchase might be purchasing decisions, and consumer choice. For a question like this, you can also think of some of the reasons why someone might purchase an electric car. Use these as search terms as well. For example, improved mileage, convenience, and government incentives. The goal here is to think of as many different words and phrases to describe the main ideas in your topic as you can. This will ensure that you aren't missing out on good resources just because they use different words to describe your topic. While you're brainstorming keywords, it's also a good idea to think about specific aspects or areas of your topic that you could also use as keywords, and which can help you focus your search. For example, you might choose to do a very narrow search by using a lot of keywords. This will reduce the number of search results you get back. Or you could choose to do a very broad search by using a few keywords. This will increase the number of search results you find. To narrow your topic down, adding specific issues, specific geographic areas, or certain time periods can also make your search smaller. If you're not in your search, try using alternative viewpoints, looking at how a topic has changed over time, or investigating the implications of the topic. These can all make your search bigger.


Hey Manuel. Hey, how are you doing? Good, how are you? Yeah, great. Unfortunately, I couldn't join the call yesterday, but Klaus told me all about it. You talked about the workflow call? Yeah. Yeah, it was only on for a short time, so. I don't know how it went as I left. Yeah, well, it is not too many outcomes. A little bit of voting case. He pressed for a few votes and stuff, but I think the first priority now is to get the talk. Yeah. And I think that's settled now. Hey, is that John? Good morning. Good morning. Hey Tommy. And Eric. Good morning. Real quick. Welcome to the main line. I was looking for the link to the document that. Sorry that people have been using to collaborate on the current effort. I had a hard time finding it. Oh, it's right here. If you scroll down. It's this right here. Okay. Oh, yep. Now it's, I see it. Yep. Nice and clearly. Sorry. Thanks. Anytime. I like easy questions. Morning, Scott. Morning. You sound tired. See, I'm a, I'm good. This is what I'm been. This is my seventh hour already. Cause I had my first phone call was at 6am. So you, I don't think you have a reason to, to whine about being tired. Oh no, no. It's my seventh hour too. I have a two year old. Okay. Let me try to bet what went up you then. My dog is getting old and not only is she going deaf, but she can't sleep through the night anymore. She's been waking us up in the middle of the night. At least once or twice to go to the bathroom. So he has a two year old. No question. No, no, don't trump me with old dog. No, I actually, I do think the, the two year old is probably harder cause the dog is easy.  But you never know what's going to happen with a two year old. Yeah. It involves him for poop. Well, mine does too, but at least I don't have to clean it. Okay. I think we've got enough topic here. Hey, Kathy, are you there? Yes, I'm here. Hello. And I think I heard Clemens laugh in there. Yes, he did. I just said, I just said good evening in German. Yes. Okay. And that's Klaus. Thank you. I feel like I'm missing somebody. Oh, there we go. Colin. Hello. I guess while we're waiting, we could talk about horror stories with the bowel movements and stuff for. Oh, no. Nope. Hey, Jim. Hey, Doug. Doug, you want to see a blast from the past? Oh gosh, sure. Okay. I'm going to turn my video on. Uh-huh. And do you remember this thing? Oh, wait a minute. Let me get, I can't see that. It's way too small. Hold on. See if I can make you bigger. What is that? Oh, now I see Heinz. Or Heinz's videos taken over. There must be an IOT demo. Oh. So I, I made this little demo board for KubeCon, like 2018. And this was the physical representation of, uh, open service broker service lights. Oh my gosh, I forgot about that. I used OSB to control my home automation. And that was my whole demo board. Uh, I figured it was, it was service broker related. I just could not remember it. That is so funny. I thought, I thought, uh, blast from the past for you is like 1998. Hey, hey, hey, hey. It was in the context of, uh, you know, Dougie crash over here. I don't go back to the soap days. Ooh. Should I start mentioning OS two? Come on. Yes, please do. Hey, yes. But the Microsoft version. The Microsoft version. Well, that was Z mix wasn't it? Oh no, sorry. That was the Linux version. No, the Microsoft version went up to 1.3 and then IBM forked and did their own thing unsuccessfully. It wasn't that long ago. I want to say maybe five or six years ago. I swear I saw an ATM machine that had like a blue screen on it, but it was the OS two logo. Wow. Yeah. Yeah, I've seen that. Yeah. Yeah, the hardware failures do that. Yeah. So Thomas, are you there? I'm on the line. Yes. Yeah, excellent. Cool. Got you. Okay. I think I got everybody. Okay, we've got a small group, but it's three after. So why don't we go ahead and start it? Oh, wait a minute. Hold on. Let me ping Mike. So that he knows we're starting because he's supposed to be talking at some point. All right. Let's get started here. Um, but up. Um, all right. Community time. Anything people want to bring up. That's not on the agenda from the community. All right. Moving forward then. We're almost done. All right. We have almost everything settled. Let's just talk about a couple of things here. So just a reminder, if you are planning on being there and going to join the face to face, put your name here just so we know it's going to be there. Um, we do actually have a time. Thursday at 1030. They basically said they could have the room anytime after 1030, but looking at the schedule. Um, between lunch being later. And then the serverless, uh, session being later. Um, and then after that, I figured people were going to start leaving and since it's the last day, I thought 1030 would be the best time to do it. Um, that way we can end the time for lunch. So that's the current time. Um, we don't have a location yet, but we should get that at some point and then not too distant future. Okay. The question with the mobile work Congress having just having been canceled. Um, are there any rumors flying around that Kukan may fall victim to the coronavirus? I have not heard anything. It's anybody else. Yeah. There was an article on the new stack and it, it's still a go. I guess we'll, we'll know more as we get closer. Okay. So there are rumors. All right. Yeah. All right. Um, last thing, um, I have a question for the booth sign up. I created a little table here for people to add their names. Um, if I would say, since I only have two slots here, um, if you need more, either add another column or just hit return and put your name in there. I was assuming we'd be lucky if we can get two people. Uh, the only thing I wanted to point out is the cloud events session is here and the serverless session is here. If you did want to attend those, you can do that. Um, you can do that at the booth at those two particular times. So sign up when you guys can. Um, all right. Anything else from coupon planning people can think of them forgetting. All right. Moving forward then. Um, All right. SDK. We had a call last week. So there was no call this week for anybody from the SDK team have anything they want to update the group on. Okay. Not hearing any, uh, discussion. So far the two groups of people who have an existing SDK are interested in doing some sort of merging. Um, but there's no discussions on how to actually make that happen. So once they actually get that settled, then we can bring the formal proposal forward and you guys can say yay or nay to it. And I suspect it will be a yay, but I want them to actually settle though the merging discussion first before we talk about bringing it in. Um, Kathy, anything you want to bid the group on relative to the workflow stuff. Okay. Yeah. So we had a meeting the first week workflow meeting yesterday. And then the team decided we're going to have, um, by, um, no monthly meetings. So every, um, so the time may change to the. Monday on the first Monday of every month. Um, and then we're going to have, um, because there's some PRs on there, which we are going to discuss on, um, next Monday. So, um, so I'm going to have one extra meetings next Monday. And so what we will discuss is, um, whether, um, the event trigger could be a single event or it could be a combination of, you know, and multiple events and multiple events or multiple events. And yeah, we're going to discuss that. Um, so I think, you know, if, you know, you're interested, you're welcome to join, we'll let more people to join and then, you know, to get the input from, um, everyone. All right. Cool. Thank you. Any questions for Kathy? Uh, yeah. First, I thank you that, uh, we can now have it every, uh, first Monday of the month because I couldn't make it yesterday. So thanks for arranging that. And, um, yeah, for the, I think for the agenda next Monday, uh, we also want to see, uh, Tommiers demo. So I just wanted to add that. I don't know if there's, yeah, but there is an agenda document. I think you'll have the link on the workflow subgroup. Yeah. There's the link right there. Oh, no, the, the, the Google doc. Yeah. Isn't that the Google doc for the, oh, that's the spec. You're right. The, um, the agenda doc. I don't have that. I'll try to get that. Yeah. I created a gender on the document there. Anyone can add, you know, any topic. I would like to discuss in the meeting. Oh, and one more question just to get up to speed. Um, there was a original design discussion mentioned that happened in around June, July, 2018. I looked it up in the log of the serverless working with many, many minutes. I requested access. If you could grant it, that would be nice. So I can see what was originally discussed. Um, which doc you refer to the, the, the, the old, the, this agenda that we're looking at here, but this is very old Google doc, Google drive document. I will try to fix that. If you could grant access. I'll try to open that up. I don't know why it's not, but I'll fix that during the call. Okay. Thanks. I, I, sorry, just a quick question. So just look, um, where are the details for the, those meetings in the Dylans for that? I will add that to the gender doc right here. When I get to find the link. So later. Well, Mike and, and, uh, Clemens are rambling on about the new spec. I'll try to find that. Okay. Okay. Yep. All right. Moving forward. Let's go ahead and jump into it then. Mike, since you are on now. Um, where would you like to focus? So I dropped the link in, uh, near the top there. I put together a candidate. Please do not consider this final. Be any means open API spec. Or what discovery might look like. Um, with a sample, uh, response. I can put this right here. I assume, right? Yeah. Okay. Let me open that for people. There you go. Um, So because of that, I put a couple more comments and edits into the, to the main doc as I kind of thought through this and, and, and thought about what it should look like. Um, in particular, I think it's interesting to think about the card melody of the return. If, uh, you should get back a source and all of the types that it produces. Or if the key for that should be, um, to get some of that information, um, I think the key is essentially source and type. Uh, so that, you know, the thing I worry about is that one of the things that discovery is supposed to do is tell you how to create a subscription. And as a producer, I've got, um, you know, Uh, And different event types that I produce. And the configuration is different for each one of those. Um, does that bit of discovery get too hard to manage? taking a stand on either side, something I think people should think about. The other thing is filters, like I'm starting to question how deep we need to go on filters in the discovery part in terms of what we should publish there. We have an opinion on this. Yeah, go ahead. In the later section, we talked about filters and Ryan wrote that up. If we scroll down to the subscription section further down, further down, further down, there's some area where we talk about filters there. There are two levels of filters, effectively, because first of all, in discovery, there needs to be a mechanism, and you're just describing that file to query, and that's a filter of sorts. Then we need to effectively have a way to filter out of, once you have found a subscription API endpoint, then you need to be able to go and tell that endpoint which kinds of events you need. We should always assume that a single subscription endpoint can potentially have overlapping numbers of events and event types, which means it can spew out many different ones. First of all, the discovery API, in some way, needs to reflect the fact that a single subscription manager can potentially yield many different kinds of events, also from different kinds of sources. Then the filter, and then for the filtering model, we need to have, in the discovery API, we need to have effectively a metadata information that says which kinds of filters are supported, because we think that we're going to have multiple different dialects of filters, including pluggable ones, and by what we're currently thinking, we're only going to define a fixed definition that everybody must support of exactly one, which is effectively filtering, and Ryan is going to define this in more detail, but this is just a cursory idea that you have effectively for source, and for type, and for subject, you have a prefix, and a suffix filter, and a complete match filter for any of those three fields, and those fields are always and. And so that's the simplest filter dialect that we think of, and if you are support, if there are multiple, more filter dialects, like a more complex one that allows you to go and do a match against all the properties, and one that probably supports an or, or you have a sequel, a sequel like filter, etc., then you would effectively have in the discovery API, or sorry, in the discovery metadata, that as you that register that, that should basically tell you which kinds of filters you can use against that subscription manager. That kind of meshes a little bit with what I'm thinking in terms of like, should there be a baseline expectation that all subscription providers have a certain baseline filter that they provide? I'd be a little bit cautious about doing both prefix and suffix matches. I worry about scalability suffix matches with some of the transfers that I'm aware of. So that's effectively a query into the cloud event that comes by, and we've been, so from implementation experience, this is exactly what we have as our event grid normal filters, and then we have advanced filters, which then also allow you to take custom properties into account, which is a little bit more complicated, and we're actually charging more for these advanced filters. So the simplest one is literally just those three fields and the equivalents right now in event grid with prefix suffix indirect match, which is fairly efficient to implement. And as soon as it gets more complicated, you get into an advanced case where you then, that is more compute intensive. And then we then also, like if you, if you start using that feature, then you also need to need to pay a little bit more. It's like you said, it's more CPU intensive. With that interplay then of, you know, I termed it domain specific languages in the discovery section, but like one of the things I struggled to represent when I was thinking through this is how to represent what that subscription specific filter language is in a machine-readable discovery doc, because I think that like you're really, the information there is really for humans, to interpret and not for machines. So if anybody has thoughts on how to represent that in discovery. So the prior art I've been referring to on our call is how MQP does this. So MQP has a concept has a so-called archetype of filter in its type system that can be applied to a so-called source definition, which means you walk up to an MQP server and say, I want to have data from this particular source. And here's a filter for it. But MQP itself does not specify what filters might be. So it's basically just a blank canvas effectively in the core MQP spec. And then there are, then there are complementing spec. We have a filter expression spec. And then there's three specs that are defined in the Apache active active MQ project that define these filter types. And the filters are identified then basically just by the type ID. And the type ID is in one case, it's or.apache door colon MQP colon JMS filter or JMS message selector. And then in the in the other cases, they're called or or goasis, blah, blah. So they have effectively just human readable names, which are identifiers. And if you are asking for a filter, you're effectively just giving it's type, and that's how we identify it. That help, Mike? Yep, thanks. Okay. Were there other areas of the of your portion of the spec that you wanted to highlight? Who are you talking to? Mike, not you, Clemens. I don't think so. I said, I put a couple of questions on there. People want to comment on my comments. If you want to look at the candidate open API spec and give me feedback, I'm happy to adjust that. I see one thing I did cross out was the Othscopes. I commented last asking last week if we should take that out. Again, that's another thing I'm not sure about how to represent in a generic manner, because how you do authentication is going to be somewhat specific. So there's two sides to that. There's making a call to the cloud subscription endpoint, and then any authentication information that the subscription provider, the producer might need to communicate with you if they're putting stuff on a topic that you own. The other thing in there is that letting individual service providers use their already existing authentication means. So if Google were to provide this using Google IAM to control which subscriptions you can and cannot create, rather than putting that in the spec, I think is a wise decision. So one of the things, I think we need to go and agree on some level of token flow, but there is effectively a triplet of authentication context, which are all kind of following on to each other. And we have to think through what that means, because first you start with a discovery, you start with discovery in a flow where you don't know anything. You just know that you want to subscribe to a particular kind of event from a particular kind of source, and you don't know where that endpoint is. Then there is effectively you need to walk up to the discovery catalog, which is somewhere near you, which is in your reach because you need to be able to see it. For that you need to have an authentication token that now goes and points you to a different service, which is elsewhere for which you also now need an authorization token, but it's not necessarily clear how you get that. And then once you are at the subscription endpoint, you then need to go and pass that subscription endpoint some form of authentication token or refresh token that the subscription manager can then use to go and push events over there. So there are three scopes, and I think we need to make them all gel with each other in some way. And we also need to have a mechanism specifically that allows an interested potential subscriber to discover something and then establish a relationship with the subscription manager without necessarily having a token in the hands. So that's going to be a little tricky. Yes, so Hines, your hand is up. Hines? Sorry, I had the world famous mute button enabled again. Just a quick comment that it's good to look at the model of the open API, but I would recommend to look at the async API, which is an offshoot where open API is directed purely to a REST request reply model. And async API is the offshoot to try and address asynchronous events as opposed to the synchronous request reply. I think it might be a little bit more eye-opening as to how you can represent some of these things, what they could capture. So definitely if we're looking at purely event-driven, open API is important, but you should also look at async API as well. Okay, jam your hands up next. Just a couple of points then. So just to follow up on Hines's comment, I think I think API was more around the definition of an endpoint that sort of consumes or produces an event rather than sort of formalizing a subscription discovery and creation model, which I think is probably what we're talking about here. But just to add on to Clement's comment, I can see huge cases in our environment where if you're unauthenticated when you do a discovery call, you might get a different response than you would if you were authenticated. Because we expose different capabilities to different partners or third parties. So I just want to throw out there that certainly from our standpoint, this wouldn't be an open book. So you couldn't just look in and say, well, what sort of events do you produce? Because that's always in the context of what your privileges are. Sorry, I can't remember the guy who ever had produced that open API spec. You can define the scopes, can't you, without actually defining how they're produced? So I just wanted to know why you took those out. Mike, do you want to talk to that one? Sorry, Mike. Sorry, I took which parts out? I thought you said you removed the concept of scopes from the open API spec. My understanding that you could still define that this operation needed a scope, but you don't necessarily need to define how it comes into being. I think when we talk about all scopes, we're starting to get into the helm of defining what the authenticator tokens look like, which we certainly could do. We could also leave that fairly unspecified that it is an off-scope to be determined by the provider. So I'm thinking about if you're using a vanilla OIDC protocol that you have a job that has a specific audience in it, for example, if you're using something like, again, Google's IAM protocol that it requires, we could specify it as a certain permission, that's really, again, thinking about things that are probably for human consumption versus machine consumption and trying to strike right balance, because I want some of the things in, some of the things here are around useful tooling, and some of the things are going to be useful to humans. Sure. For interoperability, we will definitely need to have a full, first a full REST API, and then I really think that discovery is something, so discovery might be something that is really a human-browsable thing, but also discovery very frequently is something that just drives dynamic systems in a very automated way, which means machines need to understand that as well, and need to dynamically understand that. And once you do this, then we're at the level where all of this needs to interrupt, which means we need to at least agree on a minimal mechanism for how to flow credentials, and I would at least define a binding of this model to OAuth2, because that's the most common one that we have. But there's an interaction, there has to be a discovery REST API, there will certainly be a REST subscription API, and then coming back to Heinz's point, the async API path is, that actually comes to bear when we talk about the delivery endpoints, because the delivery endpoints, they are clearly async. So there's an interaction here between these two synchronous APIs, which are the discovery and the subscription APIs, and the async path, which is then the delivery path, and I think we need to have definitions for all of them potentially. If we're starting to define this with metadata as we're starting to do this here, then having a definition that is also covered with async API, which will then effectively an async API formalization of the cloud events transport bindings, and will also be helpful. So Mike, just to draw your attention to it, Heinz pasted a link in the chat for a good async versus open API thing. I'm sure you saw that. There's also a good article on event, the cloud events and async API as well, which they're already talking about as well. The async API guys are not really sure how to represent the cloud event. They propose several different ways and I found it really confusing. We can help them. I've been talking with them because I was interested in open or async API for a Knative and cloud events, but the model is more geared towards a PubSub representation versus a producer or a consumer that would like to advertise what they want to do. Async API is a great way to visualize the topology of your entire application and all the connections and cues. But if you just want to have like, what does this one thing produce, I found it also confusing. Okay. Mike, thank you for putting this together. That helps me a lot. Just curious, anybody else have any questions or comments for Mike's section? Okay, not hearing any. Let me put you on the spot here, Mike. And this is a warning for Clemens. I'm going to do the same thing to you. So I feel like right now the stage we're at is people are adding lots of sort of questions and commentary on the site and stuff. And as a result, I feel like the actual text of the spec itself is moving kind of slowly. Would it be useful for us to pick a deadline and pick a deadline for a very first rough draft, even if everybody hates it, at least it's something on paper that people can then concretely say, yes or no, I like or dislike that. Just as a forcing function kind of thing. Meaning like get a first draft that is like a markdown on GitHub. Well, then it doesn't have to be a markdown. We can still use the Google Doc, at least for right now. But basically what I'm looking for is to get rid of all the sort of commentaries that we have throughout the entire section and write it more as a formal spec and say, here, this is what the response should look like. And basically, you know, copy and paste this into the doc and say, this is a sample what it's going to look like, a section that defines all the various fields, are they strings or the integers, are they raised, that kind of stuff and just put a stake in the ground and say, this is your view or the group's view, if you guys are still talking, of what you think this part of the spec should look like. And rather than just people just sort of randomly putting comments out there as opposed to, hey, I think we should talk about this, we should talk about that kind of stuff, just something a little more concrete for us to noodle over. And as I said, even people hate it, at least it's a stake in the ground. Yeah. So I can do that within two weeks. I'm on vacation next week, personally. Vacation? Oh, man. Yeah, actually, I was actually thinking about a two-week deadline, since I didn't want to spring it on you with only one week to go. No, I need to go somewhere warm next week. Okay, now you've got to name it. Where are you going? Oh, Disneyland. Cool. Okay. So you're okay with the first pass at a rough draft in two weeks? Yep. Yeah, I mean, I don't hear anybody saying that there's major overhauls that are needed. So I'm fine to throw it out there and then maybe somebody will object. Yeah. To be honest, I think it's more just a matter of taking all these ideas that are people, I mean, ideas that people have put there, either in comments or in like this text that I've highlighted here, and just put it more into a speckish form. That way it looks more real as opposed to just brainstorming things. Okay. Cool. All right. Before we move on to the next section, last chance, any questions or comments for Mike? All right, cool. Clemens, you're up. Yes. So we actually already covered the meat of the discussion or the one coherent piece of the discussion that was the filfer section where we then spoke about potential dialects and then spoke about the constraints we wanted to put ourselves under for an initial simple filter. Otherwise, we've been walking through a bunch of the comments that were made on the side and kind of took notes for homework. Heinz had also sent three miles of text regarding push versus pull. As we were talking about push versus pull, I think we came to the conclusion that in spite of common industry and documentation usage, in the sense that we've been using this here, it is yet confusing enough in what we're trying to describe here that we're going to use some alternatives for this also to make Heinz happy, but also to make everybody happy. So we're going to find some alternative description for pull and push terms. But the intended meaning will hopefully not change with that. That was mostly, so those discussions took up most of the call. We have then, one of the things we have also decided because of timing issues is that we're going to skip next week's call, which means there will be no updates from us. Okay. Jim, I apologize. Is that hand new or old? No, that's noops. Sorry about that. Any questions for Clemens or the rest of that sub team? So I think let me just say what the roadmap here is because that will be useful. I think where we are is that we will fill out the remaining the remaining transport dependent properties. I think we would like that we have a NAT section at the bottom. And we have been thinking that someone from Sonadio could probably go and take a look at that. Also a little bit further down, there's a section where we have defined effect of these specific transport properties. A little bit further down, even there, the protocol settings. Because we're all calling that just wonderful. Please do that. And so that would be super helpful. And then I think what we will then do next, once we have filled these things in is that Ryan will come up with an initial data model for what that filter should look like, the basic filter. And I think then fairly quickly we'll land at what a REST API might look like from the outline. And then also we'll take a look at whether how we can go and realize that REST API or that RPC API at some sort over the various transports or where we need it and where we don't. So I think we're making good progress, in spite of not taking an off week next week. Any questions or comments for Clemens and the team? So just to clarify then, we keep commenting on the dock or we're going to, should I just wait until something more... Sorry, Clemens. Please keep commenting on the dock. I think there will soon come a time that we're going to make this a little more formal problem, break this out with the documents. But for now, comments on the dock are fine. Okay. I know I made one that Ryan sort of commented on and I fully understood what he was driving out there. So one of the situations we face, and this is more of a business event issue, maybe then low level IoT style events, is where our third parties sort of turn around and want to essentially re-receive or re-pull events that have happened in the past. So, and Ryan had a very good comment that we didn't really want any sort of implication around that sort of level of complexity in this spec. But I think for me, it means I've been looking for some way for companies like ours to sort of extend the subscription endpoint a little bit and to add those extra sort of more nuanced capabilities. And if there's a generic way to do that, that would be very interesting to me. So there are two things that you might be asking. One is, if you want to have a, score up and down the event stream feature, then that might be something that you can, that is covered by the pull style API. We didn't put Kafka here, but we probably should. So I haven't, that's an omission that I thought about this week. So with Kafka or with NQP and a source filter, you can obviously go and use an infrastructure that supports this like Kafka with Strimsy or Event Hub or Azure Event Hubs. You could obviously go and have an event stream. You have been discovering this event stream using the discovery API and then the discovery API basically tells you, hey, this is the Kafka source. And then you would walk up to the Kafka source and you would attach to it and you can scroll in forward. So that's one option. The other option would be one that is probably covered by the filtering API, by the filtering model. And we have been, one of the things we're discussing is like, we're going to make this basic filter and then you can potentially go and subclass that filter with your own extensions. You can say, I want to have the events of this sort. And then you have a special filter property which says, but I want to have events from this time to this time. And then you create a new push subscription into an existing subscription manager with the assumption that the subscription manager holds a backlog.  And then there might be a further option to go and retire that subscription as soon as those events have been delivered. Is that something that you might think of there? That's an interesting twist. Yeah, I mean, I think our partners tend to just think more simplistically than that. They just sort of say, you know, so for instance, we expose a capability where you can, as a partner, go in and see all the events that have been sent to you. Yeah, you can ask for, you know, that set to be replayed. And then maybe that then becomes intermingled with your with other events that are coming your way. So some of that's triggered manually.  So but yeah, I get your point. It does imply, you know, storage on the back end, which, you know, I can fully see that probably a lot of people on this call wouldn't want to do. But it's for me, it's more, you know, can we leave gaps in the spec or mechanisms where where we can extend, you know, these subscription endpoints without necessarily breaking the spirit of what's already there. Yeah, if it can't be achieved through the sort of mechanisms that you described. Yeah, so that's what we that's, I think that's what we thought with the filtering with the filter plug ability. Because I think your scenario can be achieved through a, you have to communicate, you have to communicate to the server from a consumer perspective. You have to communicate to the server that you want to have a certain set of events again, which amounts to, in my mind, to a new subscription of sorts. Yeah, it's a historic, historic subscription of a buffer of a stream. Yeah. Yeah. And because the gesture is the same, right? If you if you go and do, if you go and start doing a subscription in quotes with Kafka, you specify an offset and start reading from that particular offset. And if you only want to have a slice of of events from the past, while you pick a different offset and you start reading from that offset and then you stop at some point. So even with a pull model, it's the same thing. And and in the push in the push world, you're going to have a the default way of doing a subscription is to get all the events that have not yet been delivered on that particular channel to avoid the word topic. And then if you if you have something that retains history, then you have to tell that push subscription manager to go and grab into that history and get you those events. And that's that is best expressed to that filter. So that's that's how so we thought of the filter. And this is why why Ryan put this in the the dialect is effectively expressed in this, right? We're going to define a dialect of filter. But then the notion is they can go and build your own filters. And of course, you can also build on the on the default dialect and then go and specify all further options. And I think of this like our effectively like the extensions we have in the core spec is that we might even have, you know, well defined multiple well defined filter dialects that you can then go and use. So that kind of history retrieval filter might be one of those options. Oh, thank you. Right. Any other questions comments? Okay, so Clemens, I'll put the same question to you. I actually I feel like your section is closer to where we want to be in terms of the first rough draft. So thank you for that. But do you think you could push for say two weeks for something you could that you would claim is a first full rough draft? Two weeks is a little aggressive three years. Okay. Just because we like we really can't get it together for next week. Okay. That's fine. I just want to make sure we don't let it let it linger too long. So Mike will be two and then you guys weigh three. Okay. Okay. Any other questions or comments related to the spec in general? Okay. If not, thank you guys for that. And I though I see my got a drop. In that case, let's talk about some PRs. Actually, let's talk about this one first only because Klaus is on the call. So Klaus, I think you may have changed the formatting down to 80 columns. But did you make any other changes on this one? No. Okay. And I think so in the comments that was just I think you proposed to give it another headline on its own. Oh, yeah, I would be open to that. But yeah, apart from that, there was no other comment asking for a change. Okay. Any questions on this one? I mean, we've been discussing on slack. So you had I think some doubts. Well, I think my questions actually are not directly related to this. I think it's more different questions. And I don't want to go into that right now. Okay. So so this has been out there for at least a week now. Anybody have any questions or comments on this? Okay, any objection to approving it then? Okay, just a quick question for you, Heinz. I'm sorry, not Heinz Klaus. Do you want to add that section header just so this stands out or not? It's up to you. I can do that. I don't really have a strong opinion about it. But I had the feeling that it's a very special case and that it doesn't need that much of attention. So that's why I just put it in the end of that section about creating events. But okay, if you want to hide it, that's fine. I'm okay with that. So okay, I'll just go ahead and merge it then after the call. Okay, thank you. Okay, there's this one. Now, this one, Jim, you had a question on this one. Yeah, sorry. I also really don't have a strong opinion. Yeah, so I think it was just the structure of it was just different to the way we do it, which was what sort of led me to some of these questions. So that, yeah, that was basically it. I mean, it could be completely valid, but it's just not structured away that we personally would do that. So I wasn't quite sure it was valid or not. So you want to change, wait, if he changes this line, I apologize, I know Zippo about the schema stuff. It's just, yeah, so that's just referring to the version of the JSON schema definition. Yeah, so draft seven versus draft four versus whatever. Yeah. Right, I'm just wondering though, if he makes that one line change, do you think it changes anything else in the PR? No, that particular line doesn't. Okay. Yeah, I think it's just more correct by doing it that way, because that schema is evolving, it's still not a standard, it's still draft form, unfortunately. The other one, the structuring one, was more to do with the way that the definitions blocks are, typically the way we do it is following that other link. Hold on. Yeah, so that's an example from the spec themselves, and if you put one up, one or down, whichever way, yeah, keep going, keep going, keep going, keep going, yes, up a bit, sorry, up a bit, up a bit, up a bit, up a bit, stop, there you go. Okay, so this is the way, typically we would do it, if we were using this definition construct, where we put definitions at the top, and then the properties of the object you're defining come further down, which means you then address it using that sort of syntax with hash slash definitions. That's the way we do it, and we typically do it like that, because that's the way the spec writers sort of, or the schema designers sort of advised us to do it. It, going back to the PR, it may be that that still works, no, it actually doesn't, because you see there the dollar ref for definitions, I don't think, I just want to make sure that somebody's run that through a code gen tool, and it does actually work, because the structuring just looks slightly wrong to me, because I think the hash means you go to the top of the tree, and then come down from there. So since definitions is not at the top, it's actually part of the properties block, I don't think the par thing works correctly. It doesn't, but isn't the definitions at the top, it's just lower down in the block? The definitions is there, it's part of properties. Properties is the root in this Oh, interesting. Okay, so I'm seeing that it's easier to see if you view, view the whole file rather than the. Okay, properties is two N. Yeah, see definitions is inside properties, it's not outside of properties. Because I see the intended two here, properties is intended to here. Where's the closing bracket for properties then? I would assume it's this. I read this completely wrong. And then, well, if I'm right, and then this, that this, no, that, if that's true, then maps to here. So I think, I think it is at the top level, it's just lower down in the doc. It's just having an early morning brain fart then. I mean, the schema reference, yeah, okay, I'll retract, I think the schema reference would like, I'd like that change though. Okay. So I'll reach out to Tim Moore, I think it's his name. I'm asking about this one then. Yeah. Okay. Does anybody else have a question about this one? About the, which version of schema to use, Heinz? Just make a comment. We have a product that's generating async API, and I was testing with the schema. And up until about two weeks ago, where we updated to a newer version of the JSON parser stuff, it would fail, but it does now pass with a new version. So depending on your version of schema parser, it will fail or pass, but the newer one seemed to be operating correctly. But it would be a little cleaner to your point where in fact, I like the suggestion of putting all the definitions at the top, and then the properties underneath, because it is a little, well, not a little, for me initially, it was very confusing because you're jumping up and down, as opposed to just sequentially being able to run through it. But that's more of a readability, as opposed to an error or anything like that. Yeah. So maybe, Jim, you should modify this comment to say rather than Liz at the same level talks about living at the top, to get the same ordering that this thing shows. I will follow my sword and accept that criticism. Yes. Okay. Okay. So I will poke in later today after you update the comments to see if he has any opinions on this one. Thank you, Jim. Anybody else have any comments or questions on this one? Or does everything else basically look okay? You guys think that the adjacent schema itself in here is basically okay? Okay. Not hearing any objection. So we'll just assume it's these minor things that Jim is bringing up. Okay. Cool. But I think that's, yeah, I think that's it in terms of what we can talk about. All right. Almost at the end of the call. Anything else for the agenda that people want to bring up? Not hearing any. Last roll call then. Grant, are you still around? No, we lost Grant. Vlad, are you there? I'm here. Hi. Excellent. Hi. Christian. Christian, you still there? What about Falco? Yes, I'm here. Excellent. And last chance for Christian. Oh, there he comes. Hey there. Hey there. I switched mics and couldn't find my, I couldn't find the window. So yes, I'm here. All right. Excellent. And Grant isn't there. And I don't, this person, Venice, we can get their last names. All right. Anybody else that missed for the agenda or the attendee list? All right. Cool. In that case, we get a whole seven minutes or I'm sorry, six minutes back your day. All right. Thanks, everybody. We'll talk to you next week. Have a good one. You too. Bye.