Patrik Stas: Hi! Book down.
Bogdan Mircea: hey, Ben!
Patrik Stas: Alright, so let's get into it, I think.
Patrik Stas: Let's see if anybody joins. If yes, it's fine, if they're not. That's also fine. I'll start by sharing my screen.
Patrik Stas: It's probably not necessary, but i'll still do it as a as a policy of hyper Ledger is
Patrik Stas: requesting to show the entire press policy notice at the beginning of the call.
Patrik Stas: So just in case it somebody else would connect during the meeting. This might be. This might start to apply.
Patrik Stas: In the meantime you're welcome bogged down, or anyone who tuned into this call later on to
Patrik Stas: to
Patrik Stas: January 26, 2,023 or 6 community call.
Patrik Stas: and I think we can. We can just get started now. So yeah, for the starter I would just like to introduce our new contributor in a Bogdan who also joined this call. I'll walk down.
Bogdan Mircea: Hello, hello.
and
Patrik Stas: yeah, Bogdan, as us may. Maybe you can Just you know, share a few words about yourself as a connected to the call for the first time.
Bogdan Mircea: Okay, sure.
Bogdan Mircea: Yeah. So
Bogdan Mircea: I guess i'm going to talk about the the technical side of things. I guess so. I recently joined Upsa. I've been a rest Developer
Bogdan Mircea: 2 s at least arrest for out here and something now.
Bogdan Mircea: prior to that. I've been working as a back-end developer, mostly in python.
Bogdan Mircea: And
Bogdan Mircea: yeah, i'm i'm really excited on working on this thing. It's actually technically pretty cool, and i'm glad to be here and be able to contribute
Bogdan Mircea: looking forward to
Bogdan Mircea: you know, hearing and discussing with.
Bogdan Mircea: So I mean
Bogdan Mircea: right now with you, Patrick, because you're here. But
Bogdan Mircea: down the line with anyone else who might join, or during the future calls, and so on.
Patrik Stas: Hmm.
Patrik Stas: Yeah, thank you very much. So let's let's get into it. So we have a few few other items on agenda. This time it's a fairly short.
Patrik Stas: so as usual, we'll start with just like a short overview of recent work which has been done
Patrik Stas: since the last call 2 weeks ago, as the previous school was skipped. So since then that was, I think, only 2 sort of significant dish
Patrik Stas: or not worthy Pr. Is merged. One of them was addressing the
Patrik Stas: how. The the the approach we take for dealing with Vdr tools.
This issue has been probably already closed.
Patrik Stas: But let me just find it first. Oh, yeah, that was originally this proposal to move Vdr. Tools, for
Patrik Stas: under a is the.
Patrik Stas: and maybe I can actually talk a little bit about this.
Patrik Stas: Given the fact that you book them are on this call now, and I can. And for anybody else this can be like also a useful background. So just a little bit background about like worldly Vdr tools is, and what is the thing we we we did here
Patrik Stas: so up until recently we've been we we had in our dependencies
Patrik Stas: like
Patrik Stas: get-based rust dependency on
Patrik Stas: fork of following repository by ever in.
Patrik Stas: We just called Vdr tools. This was basically
Patrik Stas: a fork of what previously
Patrik Stas: has been known as Hyper ledger in the SDK,
Patrik Stas: which contained L, which Content live in the and few other smaller libraries. In fact, even Levy Cx is V. 6 was originally part of this library.
Patrik Stas: and then
Patrik Stas: a basically as as a community moved on from in the SDK to like the smaller modular
Patrik Stas: modular components extracted out by British Columbia government's team
Patrik Stas: evername has, I guess, as I based on their own needs, they this decided to further develop
Patrik Stas: the the library in their own fork. So they started this new Github repo. They kind of rebranded in the SDK
Patrik Stas: Ak. Or lib de into Vdr tools instead, and starts to work on it under the evername flag.
Patrik Stas: And what happened after that is that we had basically as a Aries D. 6,
Patrik Stas: a project. We had our
Patrik Stas: additional our own needs as to
Patrik Stas: how this should further develop, and there was not much traction happening on this repository. So we then started forking it into like our own fork, and
Patrik Stas: just added a bunch of improvements on top of that. But and so we we did basically in this recent
Patrik Stas: issue, which is being created here.
Patrik Stas: and the and it's the pull request link to it
Patrik Stas: is that we have moved basically embedded
Patrik Stas: the entire or like the subset of the repository which we depended on our fork into the the main repulsory code base. So now we have live Vdr. Tools here.
Patrik Stas: We then further stripped down the code.
Patrik Stas: There was lots of unnecessary stuff.
Patrik Stas: So now it's here, and it's just easier to kinda look around and main
Patrik Stas: to explore the code or see how how things are that relate to each other, and also
Patrik Stas: also just the govern sort of
Patrik Stas: share, the same governing process for any changes in levydr tools as we have for the Ares. Vcx. Because levy they are tools is essentially at this at this point of time, still kind of foundation of as Vcx.
Patrik Stas: And so, when we do some changes, it's not gonna be happening in some.
Patrik Stas: you know, Gitl Fork, which some of the team members maintains, but it'll be just happening here, and we can properly, properly review it and and see what was really being changed.
Patrik Stas: So so that's a main sort of argument. As for why we did this, and also it enables us to iterate faster we. As I, As I mentioned, we stood down like bunch of
Patrik Stas: code from here, and so I think we can actually
Patrik Stas: do some further iterations
Patrik Stas: in that sense.
So that's that's this item. Here we have embedded Vdr. Tools into repo.
Patrik Stas: and then moving on to the next item was no just drier addition.
Patrik Stas: the new feature to add support for the non mini mode mediated connections, so it's not possible to work with every connections without necessarily dealing with the agency.
Patrik Stas: provided the
Patrik Stas: Maybe it's your agent
you can. You can instead handle the meditation all the messages yourself.
Patrik Stas: and now moving on to the like next section. So for the things we have in progress, maybe i'll start just a short shared word about the second item.
Patrik Stas: which is a poc. By George.
Patrik Stas: from unnamed labs.
Patrik Stas: working on like proof of concept. For how UN, if I Library, can be integrated with a Vcx. So this is kind of like
Patrik Stas: more modern approach is for how to
Patrik Stas: how to provide F. 5 for essentially any languages
Patrik Stas: from from Ross as opposed to the way we currently do it in.
Patrik Stas: I don't know the technical details about this, so we'll have
Patrik Stas: oh.
Patrik Stas: probably George on a call next week, according to what he mentioned on discord.
Patrik Stas: and he will talk a little bit about this. Give us some like technical, technical intro into the approach they can, and how it all works, and how you need the fireworks. So sh sh! Sh sharing is caring sharing knowledge.
Patrik Stas: Yeah. So again, anyone any any users of, believe me, 6. I would just like to point out that
this this can be
Patrik Stas: a useful and in a long run.
Patrik Stas: Libby Sig is not meant to be like the first-class citizen of the of the Hyper Ledger, a Vcx project. It's really just the areas Dcx create and all the other things are on top of that. It's like additions. But
Patrik Stas: I we we cannot guarantee that, like long, long term support of obliviousx, although I think 2,023 should be Still, fine as as we in up some, we our self have a interest on on still basically building on top of it.
Patrik Stas: but just throwing the throwing in alder it to be aware of this sort of the up ups, ups, ups, ups.
Patrik Stas: But yeah, if anyone's willing to kind of take on the Libby 6 afterwards, that that's cool, of course, and there'll be very much welcome.
Patrik Stas: And now, yeah, i'll just let's move to the like. The interesting. I think the main highlight of this call we just
Patrik Stas: and other Peels.
Patrik Stas: another poc from Bogdan
Patrik Stas: on the call.
Patrik Stas: and this is essentially well. We have also issue for
Patrik Stas: for this Pr. With more information
Patrik Stas: that will be this one.
Patrik Stas: So there's
Patrik Stas: So there's a detailed description of.
Patrik Stas: for this is income passing
Patrik Stas: in my view just before I bog down I get it. Take Take the my take in my again, and dwell into like a more details. In in my view, it's like
Patrik Stas: I see like a proposal for
Patrik Stas: or like candidates, or almost like a candidate for, like a next generation sort of Api.
How we could deal with State machines.
and just how how the Api exposed to other rust rates should look like.
Patrik Stas: and and this is also opportunity to just kind of like fix any sort of technical depth. Is this this work here done by Bogdan is kind of starting from stretch just sideways, mostly sideways from existing code. As you can see, there's no
Patrik Stas: no code removed, only edit basically new new alternative approach.
Patrik Stas: So, having said that i'll, i'll leave a word to to book them to just kind of
Patrik Stas: take us through it.
Patrik Stas: It's a high level.
Patrik Stas: So i'll stop sharing now, and
Patrik Stas: the floor is yours. We'll go
Bogdan Mircea: that in just 1 s. So
Bogdan Mircea: here.
Okay.
okay.
Bogdan Mircea: let me know when you can actually see something.
Patrik Stas: Yeah, I see it's all good.
Bogdan Mircea: Okay, so
Bogdan Mircea: like you like you pointed out. So I mean, I was a bit
Bogdan Mircea: like, ultimately.
Bogdan Mircea: as I am working on this I would obviously like to see it being used.
Bogdan Mircea: But
Bogdan Mircea: since we discussed about this
Bogdan Mircea: had the opportunity to discuss this.
Bogdan Mircea: sometimes
Bogdan Mircea: there isn't be a lot of stuff depending on the current good, and
Bogdan Mircea: it would probably be a good idea not to touch it. But maybe in the event that this would be, you know, like an an approved approach.
Bogdan Mircea: maybe slowly, transition to this and the potato code. Is
Bogdan Mircea: it forward?
Bogdan Mircea: And the general idea behind this
Bogdan Mircea: is
Bogdan Mircea: pretty much the fact that
Bogdan Mircea: right now, if you have a look at
Bogdan Mircea: the actual code, you will see a lot of
Bogdan Mircea: basically the the entire connection with all its possible states is a composition of enams and stuff.
Bogdan Mircea: and you have to constantly verify
Bogdan Mircea: what state you're in, and what you should be able to be doing. And if you're not supposed to do something in a certain state, you throw out an error and stuff like that. And there's a lot of basically a lot of conditions happening.
Bogdan Mircea: you know, because of that.
Bogdan Mircea: And
Bogdan Mircea: there is a pattern that we can actually use. It's somewhat more, a very specific thing, I believe Haskell can also do stuff like this.
Bogdan Mircea: but it's something called a type state pattern, and it's very, very cool for state machines and rust.
Bogdan Mircea: It essentially relies on sort of like embedding the State in
Bogdan Mircea: the actual types that you're using.
Bogdan Mircea: and this can be done in multiple ways.
Bogdan Mircea: but essentially like 1. One interesting idea or one, let's say common idea is to have generics in place.
Bogdan Mircea: so that you can actually take advantage of was generic in the organization and implement.
Bogdan Mircea: Let's say methods for a collection of types based on on their generic parameters.
Bogdan Mircea: So essentially
Bogdan Mircea: in a, maybe I can actually pull up my
Bogdan Mircea: my actual code
Bogdan Mircea: to represent the
Bogdan Mircea: for to illustrate the current approach.
Bogdan Mircea: So here
Bogdan Mircea: we basically have the parent connection, which is the let's say, developer or end user exposed to type. And then this depends on this enam.
Bogdan Mircea: which
Bogdan Mircea: then goes down to some
Bogdan Mircea: state machines.
Bogdan Mircea: and there's one for the invider, and there's one for the invite D, and so on.
Bogdan Mircea: And basically throughout the code here you constantly have to check
Bogdan Mircea: what
Bogdan Mircea: variant of the in and this is, and take some action
Bogdan Mircea: or not. Take some action.
Bogdan Mircea: and then this happens at the other layer 2,
Bogdan Mircea: and it just keeps going like this.
Bogdan Mircea: In contrast.
Bogdan Mircea: The idea here is that basically all these methods and all the
Bogdan Mircea: let's say functionalities of the type is available to absolutely any state, whereas in a type state pattern
Bogdan Mircea: you essentially restrict, and you can
Bogdan Mircea: code be restricted to compile time, the capabilities of the connection based on its state.
Bogdan Mircea: So, for instance, maybe a
Bogdan Mircea: a proper example would be looking at the natural implementation.
Bogdan Mircea: So let's say, in the invited state
Bogdan Mircea: of an invited connection.
Bogdan Mircea: you want to be able to handle the request.
Bogdan Mircea: Now, this method is
Bogdan Mircea: basically restricted at compile time, to only be available for this particular type. You cannot call it in a different, in a different state in a different ion in the invitee connection. You simply cannot do that because it's not
Bogdan Mircea: program. It's not
Bogdan Mircea: okay.
Bogdan Mircea: And besides, the maybe obvious benefits of this in the sense that you can transition from one state to another with a guarantee that you cannot miss things up
Bogdan Mircea: another advantage, and I honestly see it as a big thing
Bogdan Mircea: is the fact that you can now also reliably use the stuff in this particular state.
Bogdan Mircea: So, for instance.
Bogdan Mircea: not necessarily sure. This is the perfect example. But
Bogdan Mircea: the requested state will store a request. Right? So we have this here
Bogdan Mircea: now.
Bogdan Mircea: In the more in the holistic approach, the the current approach with the enums and all that
Bogdan Mircea: you constantly have to check. Do you have a request there? Can you use it?
Bogdan Mircea: And so on; Whereas here, when you are in the
Bogdan Mircea: invite their connection, which is just an alias for a connection with an inviter, a generic parameter in the requested state.
Bogdan Mircea: You know for sure that you're going to have a request in your state.
Bogdan Mircea: and you can
Bogdan Mircea: take it full advantage of that without having to check.
Bogdan Mircea: and it implies or coding some sort of conditions
Bogdan Mircea: and and and stuff like that.
Bogdan Mircea: And this is really powerful for
Bogdan Mircea: for really a great number of applications, and it's common it's a pretty common pattern and rust.
Bogdan Mircea: Yeah. So this is pretty much the overall idea. Now, this is still in sort of like an infant stage. I've
Bogdan Mircea: pretty much. I've done a lot of effort to curate the actual methods, and they look a lot better now.
Bogdan Mircea: Also factored out some cloning and stuff.
Bogdan Mircea: It's not yet completely usable. I'm. Still working some things out.
Bogdan Mircea: But this that's pretty much regarding the the advantages of this approach so
Bogdan Mircea: compiles compile time, guarantees that we cannot mess things up, and then you don't have to deal with as many errors, because there cannot be erased
Bogdan Mircea: simply because you cannot call certain methods
Bogdan Mircea: the the the guarantee of the state in your current dive is also something really important. So again, the less conditionals.
Bogdan Mircea: And
Bogdan Mircea: yeah, this would overall increase performance simply because you don't have to go through all the matches and the variance, and so on.
Bogdan Mircea: Let's also talk about the disadvantage of this. It's pretty much just one. But I guess the ramifications are
Bogdan Mircea: can can be a couple.
Bogdan Mircea: So
Bogdan Mircea: because you have different
Bogdan Mircea: states encoded in the type, you essentially have different types.
Bogdan Mircea: So
Bogdan Mircea: just because this uses a generic.
Bogdan Mircea: it's mainly useful for implementing common stuff like this where you want to implement
Bogdan Mircea: methods for absolutely all the States. As long as you rely on the common stuff, you can do that, and these methods will be available for all the States.
Bogdan Mircea: But in the end they are different types. So this will not be
Bogdan Mircea: the same type as this. And what this also means and rest is that paddling we're storing them
Bogdan Mircea: in. Let's say, a container like a vector or stuff like that
Bogdan Mircea: is not necessarily.
Bogdan Mircea: I don't want to say impossible. There are ways to do it, but it's not straightforward anymore.
Bogdan Mircea: But then
Bogdan Mircea: this this would pretty pretty much be the disadvantage, and the implications are like, I said, storing them in memory. You have to
Bogdan Mircea: either use some sort of trade object, or
Bogdan Mircea: as a user, If you want, you can implement your own enum over these.
Bogdan Mircea: or simply like, instead of storing all of these in a single vector you can have multiple vectors for each possible state.
Bogdan Mircea: So you pretty much have to work around this stuff a bit.
Bogdan Mircea: so it's. It kind of makes things a little more verbose.
Bogdan Mircea: But that's pretty much the let's say the downside of having all those guarantees and the performance increase.
Bogdan Mircea: Yeah, so
Bogdan Mircea: I guess that would be pretty much the the overall story
Bogdan Mircea: I am currently working on
Bogdan Mircea: like handling serialization and thiserialization in a more organic fashion essentially serializing. This is fairly easy. As long as the generic brand there is important materialize. You can do that. You can store it, and that's not a problem.
Bogdan Mircea: because you start from a concrete type.
Bogdan Mircea: and you will ultimately get the stream.
The
Bogdan Mircea: more convoluted processes when you want to d serial, deserialize a string into a connection, because you sort of have to know
Bogdan Mircea: the
Bogdan Mircea: and type of the connection like the actual state, and whether it's an invited or an invite. And my idea regarding dealing with that is pretty much having a helper.
Bogdan Mircea: a helper type
Bogdan Mircea: that you can serialize into
Bogdan Mircea: like, and it as an intermediate type, and then store this as a string. And then this relies into this type.
Bogdan Mircea: And then basically just process this
Bogdan Mircea: to essentially
Bogdan Mircea: identify the end type of your connection.
Bogdan Mircea: These things are not yet public. So maybe the attributes would have to be public here, although No, actually no, you don't need them to. I implemented this from stuff. Okay, so essentially what you would want to do in this case, You.
Bogdan Mircea: If you have a connection like this, you will want to look at the state
Bogdan Mircea: which and place this regard to naming. I just didn't have a better idea right now. But if you you want to look at the state, is this: the term is the actual type, and you want to know whether it's an invite or an Id. And then there are. These are other enams that actually contain the
Bogdan Mircea: the dedicated state. So, as you branch through the matches, you will end up with.
Bogdan Mircea: let's say, a connection for an invite there in
Bogdan Mircea: a requested state.
Bogdan Mircea: Now
Bogdan Mircea: again, because these would be different types. You cannot just return them.
Bogdan Mircea: you know blindly. You either have to again have some sort of structure where you store these organically, but
Bogdan Mircea: you can also simply send these to other parts of your code where they should be processed. And when you think about it.
Bogdan Mircea: It kind of sounds a bit counterintuitive, especially when I don't for people that maybe
Bogdan Mircea: I don't didn't really deal with a lot of painful stuff in rust before.
Bogdan Mircea: But these actually this this thing actually has certain advantages.
Bogdan Mircea: because in the end.
Bogdan Mircea: even when you take
Bogdan Mircea: this connection here.
Bogdan Mircea: like you just deserialized this from a stream.
Bogdan Mircea: You still have no idea what what this is, and what state is in, and what you should be doing with it.
Bogdan Mircea: So you pretty much Have 2 options. You either branch through the the Enums and see the actual state, and then take an action
Bogdan Mircea: and continue, for from there, or I guess you could possibly also just like, take the process from from scratch. I don't know if that's even a good idea and
Bogdan Mircea: see where it fails and stuff. But anyway, the the point is that you still have to
Bogdan Mircea: sort of detect what state this will be in
Patrik Stas: It's it's a i'll just. I'll just jump in here for a second. Yeah, it it is like, actually good point, because like it, it basically with the approach you are proposing here, you need to as a developer. You need to know
Patrik Stas: at the point of this aerialization like you need to decide what you're gonna be serialize into which state and you have to make the assumption. But actually, in fact.
Patrik Stas: in practice. And from what I've seen in the world, actually, I always make the assumption like, yeah, and I don't have to specify it explicitly. But
Patrik Stas: if I receive, let's say a connection request message.
Patrik Stas: I automatically assume that. Oh, okay, this means that i'm expecting a message, and i'm
Bogdan Mircea: but it but it's not necessarily true. Yeah. So again, this it's it. It is a bit more verbose. I can't argue with that.
Bogdan Mircea: But rust tends to be like that. And again, this has the advantage of maybe also separating the
Bogdan Mircea: like the processing parts of your code, so that you can
Bogdan Mircea: know exactly what's gonna happen with something and where where? Exactly in the Co. It happens so like you said, you get, you just realize a connection here. You get a connection request, and you might imply that. Okay, then, this is in the proper state to handle that. But there is no guarantee that it will be.
Bogdan Mircea: And
Bogdan Mircea: then you.
Bogdan Mircea: you try to use a connection request. You get an error, and then you gotta keep handling that you again. Still, don't know what what state that's in?
Bogdan Mircea: Basically, with with this approach just fail. Fail early, right? Because instead of failing in like, you have to know, it's not an failure. You're not even allowed to fail Doesn't make it. You can get a connection request.
Patrik Stas: Yeah, I know. I guess it depends from like how.
Patrik Stas: what kind of logic you wrap around with that that state pattern with. But assuming that
Patrik Stas: you know I store something in this drink, and then
Patrik Stas: a connection in string, and then I you know, I receive, let's say, a
Patrik Stas: a connection request
Patrik Stas: now in a code. If I I know you have like some this smart kind of pattern you are showing now, and also yesterday to me.
Patrik Stas: But if you just like, try to like force, you know, just make that. Make this statement in a code like I want to be. Serialize this into connection, and then you specify the particular. You know you actually supply the generic parameter. It's like on to the serialize this into request, state, invite.
Patrik Stas: invite her. This realization will fail. Yeah, it will. We will pay on serialization. So essentially, just like fail earlier, like you would fail otherwise, because otherwise you would successfully be serialized. But then you would fail on like process request or something like that.
Bogdan Mircea: Yeah. So
okay.
Bogdan Mircea: I I guess that's that's really good point.
Bogdan Mircea: And it's occurred to me after we
Bogdan Mircea: we had our chat yesterday that
Bogdan Mircea: it does make things proposed, but it's not necessarily wrong. It just forces you to take some actions that you probably should have taken anyway, and it makes you scatter against the
Bogdan Mircea: the logic of your code a bit a bit more again increasing verbosity, because you will have to treat the individual States as their own types. So you kind of have to have what's a dedicated logic for them.
Bogdan Mircea: But you would want to do that where you would need to do that, anyway.
Bogdan Mircea: Maybe just having a common type would allow you to
Bogdan Mircea: right. The I don't know just
Bogdan Mircea: a couple of functions, but maybe you can also emit some stuff.
Bogdan Mircea: Just not
Bogdan Mircea: not think about it at that time, like like this case with.
Bogdan Mircea: you know, the the incorrectly serialization, or just the unexpected type.
Bogdan Mircea: whereas this would force you to basically handle
Bogdan Mircea: everything that you want to handle as well. Because, let's say, I also thought about this. So consider that you would only want to. You're been in building a small agent, maybe, for an embedded device, and you only want to.
Bogdan Mircea: You won't. You only want that agent to act as
Bogdan Mircea: as an invite. Let's say so.
Bogdan Mircea: Then you only have to deal with the states of the Invite D, the code for the invite. There is basically just going to be that code, and the compiler will eliminate it. And you basically only have to treat the States that you're interested in like going to step further. You can also assume that
Bogdan Mircea: in a small emitted device
Bogdan Mircea: you will only want to store a complete connection.
Bogdan Mircea: And let's say you start up a connection. You you know you get an invitation and visual, an Id
Bogdan Mircea: you go through through the political, and
Bogdan Mircea: when once you get to the end, that's when you want to store it. I know, somewhere in some persistent storage.
Bogdan Mircea: So again, when you retrieve it, you know that you're expecting a
Bogdan Mircea: complete connection. There's no other possible state, because there's that's what you want to Slowly, if you try to disrealize it to something else that you never fail. So you know something went wrong, or if I don't you never store anything, you can fry me
Bogdan Mircea: like the connection protocol, and so on. But essentially it segregates all this logic so that you also simply have to deal with what you're interested in. And when you're interested in
Okay.
Patrik Stas: Yeah, yeah, it's it's good point. And I have actually few few like additional nodes myself here as you are speaking, so I just I just told as a as a like a value preposition. I guess I realized that
Patrik Stas: probably lots of unit tests, you know. Lots of stuff we have now
Patrik Stas: as a unit test for the State machines
Patrik Stas: are for transitioning to an invalid state. Yeah, they could be actually like pretty useless going forward, because the compound would certainly actually go. And yeah.
Patrik Stas: well, they are only
Patrik Stas: sorry.
Bogdan Mircea: The test would only be compiled when you actually do like, run the tests. But yeah, I mean, yeah, I was. I was wondering about the value of those test, you know, but and I and I for a moment I feel like they become useless, because the compile time pretty much
Patrik Stas: it will assure the things which that are testing currently. But then I realize that we are making changes here on like a sort of like up.
Patrik Stas: Let me think. Yeah, I think kind of like upper level, because
Patrik Stas: we're still going to have the state machines
Patrik Stas: as we have. We have them today. Wait, do we now now to review the diagram? I I draw in your Pr.
Patrik Stas: And let me see.
Bogdan Mircea: No, yeah, no, I guess I guess we're still gonna have it. I'm not sure about like the media connection is definitely gonna stay. I'm not sure about that. That other connection.
Bogdan Mircea: As far as I know it's quite recent.
Bogdan Mircea: so I don't know if we can just deprecate this in favor of the live state machines. But what i'm referring to is is if you click into the Sm connection and on structure
Patrik Stas: you have a yeah. And basically here there's a bunch of unit tests, you know, and these are unit. Those are often like. Sometimes they are checking like, if you are in a complete state like you shouldn't be able to process.
Patrik Stas: And so, basically, with the changes you do this test become useless? Because I mean we will not. It just won't be possible anymore, right to make that error.
Bogdan Mircea: hey? Exactly. Because there's no like no coded path for that to happen. So
Bogdan Mircea: that's that's pretty much the beauty of it.
Patrik Stas: Yeah, yeah, it's it's it's it's cool.
Patrik Stas: And then yeah, I would. I You know I guess the more I think about think about it. It it does seem just like kind of more conceptually correct, like
Patrik Stas: by using harnessing the like compiled guarantees, and just
Patrik Stas: make it
Patrik Stas: kind of like, basically provide a more information and compile time. And then, if you actually, if if you would actually want kind of
Patrik Stas: if I if somebody would want to like really preserve kind of the old Api.
Patrik Stas: which you know, was exposed before. Essentially, I think it would be possible to build like one more layer of connection, some sort of, you know, whatever collection, wrapper, or whatever what we called around it.
Patrik Stas: which would have all of the methods. And it was just kind of wrap around this. All these, like States and State machine, these realizations and just kind of provide the same Api we currently provide in the connection handle, I think.
Bogdan Mircea: Yeah, it will definitely be possible.
Bogdan Mircea: I mean.
Bogdan Mircea: I it's not really the the goal of this, like Ideally.
Bogdan Mircea: you would want to depend on on the type staying machine, because otherwise you
Bogdan Mircea: basically used to approach it, it will still be beneficial.
Bogdan Mircea: Don't get me wrong. So maybe for people that don't want to switch to that. Maybe not.
Patrik Stas: I. I think that that's kind of
Patrik Stas: possibly something will that I I guess I I don't like.
Patrik Stas: get ahead of myself. I thought that it's something that will probably end up
Patrik Stas: happening in Libby Cx. But I know you are already working on it, and probably have a better approach, so
Bogdan Mircea: i'll just. I'll just wait with myself on on on the i'm still working on that I didn't get to to finish it. I I would like to finish it for the call, but
Patrik Stas: it's probably gonna take me some more time. But maybe we can. We can talk about that next week, I guess I don't know sure, sure. And so. And and the last point I have in my note here is
Patrik Stas: I just, I guess, the open and question kind of for ourselves. And the community
Patrik Stas: is basically what, if you know, we go it forward with this. And as as time proceeds, more, more and more in favor. Actually.
Patrik Stas: I was just wondering how
Patrik Stas: how would we kind of go about it in
Patrik Stas: in terms of like I said, 2 options basically like
Patrik Stas: that we could write
we.
Patrik Stas: It's definitely a good approach to like start writing like a sideways, as like new implementation as a new feature. Just new code additions.
Patrik Stas: and then have these 2 implementations.
Patrik Stas: But then I was thinking, like, you know, if we're going to keep the implementations like basically of the same thing, one legacy and one the new one.
Patrik Stas: It's gonna all it's gonna consume like our, you know, maintenance, energy, and capacity unnecessarily. So it will be ideal if we can
Patrik Stas: really just get rid of the legacy code as soon as possible, as as this is ready. And so I guess, for that to happen. Really, we would have to
Patrik Stas: just make sure that
Patrik Stas: essentially, as far as the serialization, the serialization can be like preserved. Then there's no reason why the new implementation couldn't be used in the vcx instead of the old one. And so.
Patrik Stas: once we have them in place, and we are sure it is backwards compatible.
Patrik Stas: Then we can literally just
Patrik Stas: purge all the old code, and just just maintain the new new implementation. And then, I guess, like in a in a second step we could actually
Patrik Stas: like a complete separate issue. We could make a breaking changes to the serialization.
Patrik Stas: and just make it much more probably simpler and natural. Because now, when we, when we gonna do this process of retrofitting the serialization format, I think it's gonna be it's it's gonna end up like really like it's gonna be ugly code, but as just necessarily evil to
Patrik Stas: avoid having to maintain 2 implementations simultaneously.
Patrik Stas: Yeah.
Bogdan Mircea: and none of you actually mentioned it. I I also wanted to maybe illustrate another point of this.
Bogdan Mircea: Hmm.
Bogdan Mircea: It has something to do with the fact that this is a State the type state pattern, and it takes advantage of these generics, but I guess it. It also has to do with the fact that it's sort of a refactor. So there's a lot of things that you know I could go through and through and
Bogdan Mircea: have a second look at, maybe stuff that nobody will bet for for some time.
Bogdan Mircea: But yeah, I wanted to to basically showcase that.
Bogdan Mircea: So let's say, just considering the State machine. So this has like 235 lines. The southern one has
Bogdan Mircea: 286, let's say 700,
Bogdan Mircea: and if you take the
Bogdan Mircea: the controller or the handler, sorry as well, you end up with over a 1,000 lines. And
Patrik Stas: if you look at this, this is plus cause the unnecessary unnecessary test code. Basically
Bogdan Mircea: Well, yes, yeah, You could consider that as well. That's also code to maintain. But so this is less than 200. This was 110, let's, say 300, and then this is another 200 or so. So this basically reduces in in half the States are not that much different? Maybe they're even less code as well.
Bogdan Mircea: There is obviously a different approach, and there are some other stuff. And also you could maybe count the like the serialization stuff.
Bogdan Mircea: That would also be something. But essentially
Bogdan Mircea: I mean to me this looks
Bogdan Mircea: maybe I mean that's definitely an
Bogdan Mircea: I guess a subjective opinion because I wrote it. But to me it looks a bit more
Bogdan Mircea: clean and maintainable and easy to just go through.
Bogdan Mircea: I guess.
Patrik Stas: No, I agree. I agree. I mean, objectively, as you pointed out, shorter, it's the methods are further there. There is less code.
Patrik Stas: It looks simpler.
Patrik Stas: So I I agree. I think it's objectively. Simpler.
Bogdan Mircea: Yeah, and it's easier. And you track like it's easier to go through, even just, you know.
Bogdan Mircea: Like just having to look at it. You can see the return type. Okay, you're going to get the responded State. What is this going to do? And then you can just go through that.
Yeah.
Patrik Stas: Yeah, that's that's cool. I'm: I'm: getting excited about this
Patrik Stas: very cool.
Okay.
Patrik Stas: Okay. So I guess I guess we can close it with this. Thank you for yeah, Thank you for presentation.
Patrik Stas: I was.
Bogdan Mircea: I really wish that maybe I would trust
Bogdan Mircea: would be more control for it. But this was already a a good amount of work.
Bogdan Mircea: I'm gonna keep them working on it. So maybe next week I can actually, you know, have a little
Bogdan Mircea: like a proper poc, maybe an an example of a pedestal to, and some stuff that was actually.
oh.
Bogdan Mircea: straight in the
Bogdan Mircea: more presentable fashion, the actual benefits, and maybe even that you know the downside of different types, and how you can work around that for how I would work around that.
Bogdan Mircea: But yeah.
Patrik Stas: yeah, let's see. Also, i'll be I'll be curious about the thoughts from George. He he had. You know i'm curiously like significant
Patrik Stas: my contribution to the library as well.
Patrik Stas: So i'll be i'll be bringing him if they can, if they can take a look as well and see what he is thinking.
Patrik Stas: Yeah, but let's move from from this now.
Patrik Stas: and there's one more point here is for upcoming work. Honestly, i'm not sure right now, I think, for the like. Next week we'll be pretty much
Patrik Stas: busy
Patrik Stas: with the the state pattern refactoring and discussions around it, and how to kind of integrate it
Patrik Stas: and basically start using it as soon as possible. So we don't have to do like, yeah maintain 2 implementations in parallel.
Patrik Stas: So I think they will kind of keep us busy.
Patrik Stas: Possibly we might actually like drop in some further
Patrik Stas: contributions from upset, I guess, depending on our capacity, but they will see. I think we don't want to commit to any extra items right now. Yet
Patrik Stas: if anything, there's like kind of backlog here for anyone looking to pick something up.
Patrik Stas: I think. One thing we ran into now. Book done in the in the Pr. I. I dropped there a common was the
Patrik Stas: a
Patrik Stas: the video is over, and I thought it was here, and I don't see it.
Patrik Stas: So i'm sure there is an issue for it. I've seen it.
Yeah.
Patrik Stas: So maybe that could be actually like pretty useful to make the code even pret. There.
Patrik Stas: we'll see.
Patrik Stas: Well, and I guess this state machine thing
Bogdan Mircea: It would be definitely a useful component.
Patrik Stas: Yeah. Yeah.
Patrik Stas: Well, I guess, Having said all this, and going through our agenda, I think we can conclude that this is a pretty cool meeting and a nice nice presentation from your cell book. Done.
Patrik Stas: Thank you very much. Thanks for anyone tuning in, and we'll connect here again
Patrik Stas: in the week, same time always Thursday, 9 a. M. Atc.
Patrik Stas: Oh, thank you, bookdown and thank you. Everyone cheers you.