WEBVTT 00:00.000 --> 00:16.840 So, my name is Mitri Lenio, I'm working for Perkona and I'm going to talk about open 00:16.840 --> 00:25.720 souls support for routines in JavaScript, Interconne server. 00:25.720 --> 00:37.720 And if you work about me, I'm working and I have been working in my school 00:37.720 --> 00:44.960 ecosystem since 2003, participated in development of such things as storage routines in 00:44.960 --> 00:53.440 my school, triggers support with new data dictionary in my school and now there's a 00:53.440 --> 00:59.560 work for Perkona and particularly I'm busy with JavaScript support project. 00:59.560 --> 01:03.080 Okay, so let's start. 01:03.080 --> 01:04.680 So, what's the background? 01:04.680 --> 01:15.440 The ground is pretty simple, Oracle started to support storage programs in JavaScript recently 01:15.440 --> 01:17.880 in my school server. 01:17.880 --> 01:24.640 It became generally available in my school 9-year-old and it's available in innovation 01:24.640 --> 01:31.760 releases on the so far, but I'm sure it become available in some altias release later 01:31.760 --> 01:34.480 as well. 01:34.480 --> 01:39.320 There is a GoChainHour, the GoChainSPritus simple, it's either enterprise on the 01:39.320 --> 01:47.600 future or a cloud on it, so you can't have this JavaScript routines in the community 01:47.600 --> 01:51.720 version of my school. 01:51.720 --> 02:00.160 So Perkona decided to provide an alternative solution which is free and open souls and we 02:00.160 --> 02:07.640 are working on it right now. 02:07.640 --> 02:16.920 So, okay, and there is this thing with JavaScript with Versus Js, as you probably know, 02:16.920 --> 02:25.800 JavaScript as a trademark by Oracle, so I will try to avoid this use, use, using it. 02:25.800 --> 02:35.640 So why do we want programs stored programs in some other language when stored program 02:35.640 --> 02:38.840 language will already have in my school? 02:38.840 --> 02:46.640 Well, if you try to write stored programs in my school stored program language, you 02:46.640 --> 02:50.760 probably are not very happy, person. 02:50.760 --> 02:58.200 It's fairly data-tling which, and let us be honest, it's not a by spread language, so there 02:58.200 --> 03:02.400 are not that much people out where who know it by heart. 03:02.400 --> 03:13.960 So it's a bit hard to find people who are ready to work with it right away, and let's 03:13.960 --> 03:19.200 it, and also there is performance issues as well. 03:19.200 --> 03:25.720 But if JavaScript is, and or yes, it's very different, it's a fairly modern language with 03:25.800 --> 03:37.240 many features, it has array support and like some other language, it's language which 03:37.240 --> 03:41.800 people do really know, right? 03:41.800 --> 03:51.600 I think it's maybe a bit less popular during last few years because of AI stuff and maybe 03:51.680 --> 03:53.840 Python, or take it. 03:53.840 --> 04:02.000 Nowadays, but still according to Stack Overflow survey, at least 62% of developers 04:02.000 --> 04:07.840 written something professionally in JavaScript during the past year. 04:07.840 --> 04:13.080 It's quite an adoption. 04:13.080 --> 04:18.280 Lots of people writing in it, lots of code out there in JavaScript, so lots of possibilities 04:18.280 --> 04:21.320 for code reuse, right? 04:21.360 --> 04:27.600 It's the second most popular language on GitHub of the Python. 04:27.600 --> 04:40.160 It has millions of packages, which are ready in NPM Registry, lots of tools for developers, 04:40.160 --> 04:49.640 and finally JavaScript thinks to its use and browsers, and in Node.js, it's fairly optimized, 04:50.640 --> 04:58.160 so we have JavaScript tangents, which provide really nice performance. 04:58.160 --> 05:06.760 For example, we did a small benchmark with our implementation and compared a simple function, 05:06.760 --> 05:12.680 it's basically function which does data masking. 05:12.680 --> 05:19.280 We implemented the same function in JavaScript, we had an implementation as a data 05:19.280 --> 05:26.440 masking QDF in C, and we also implemented it in the same way in the MySQL story 05:26.440 --> 05:28.240 tricky language. 05:28.240 --> 05:39.240 The difference was quite significant, so JavaScript was 100 times faster than the SQL, 05:39.240 --> 05:47.800 like the story procedure language, and UDF's was still faster, it's C, but only 10 times 05:47.840 --> 05:49.840 when JavaScript. 05:49.840 --> 05:59.240 And the mileage might vary if you're just, for example, running SQL from your JavaScript, 05:59.240 --> 06:04.000 probably the difference will be less pronounced, on the other hand, if you do some computations, 06:04.000 --> 06:09.760 which are supported well by JavaScript, the difference might be much more pronounced. 06:09.760 --> 06:15.760 These were basically a string manipulation functions, okay. 06:15.760 --> 06:21.760 So what did we do? 06:21.760 --> 06:30.760 Actually, when Oracle has implemented JavaScript support, it implemented it as a component, 06:30.760 --> 06:40.760 so we have a component API, and support for a server to call a component to process 06:40.760 --> 06:51.760 routine in some external language, and we also have an API for such components, implementing 06:51.760 --> 06:57.760 the external language, to get additional information about routine, to get parameters, 06:57.760 --> 07:04.760 and overall we actually have this component API, which allow to do certain things in the core of a server. 07:04.760 --> 07:15.760 Like find out if connection was killed, run purely in the column connection and so on. 07:15.760 --> 07:18.760 So we basically implemented such a component. 07:18.760 --> 07:24.760 One great thing about implementing external story routine, language as a component, 07:24.760 --> 07:28.760 is that component should be enabled to work. 07:28.760 --> 07:32.760 So if you do not use with feature, you do not enable with component, 07:32.760 --> 07:46.760 and you do not take any risks related to allowing executing code, say, in JavaScript. 07:46.760 --> 07:54.760 We use Google V8 engine for execution of a JavaScript. 07:54.760 --> 07:56.760 It's used by Chrome. 07:56.760 --> 08:01.760 It's used by Node.js, PLV8, use it. 08:01.760 --> 08:10.760 As far as I know, upstream use as a growl VM, which are their own engine for JavaScript execution. 08:10.760 --> 08:15.760 But V8 is much more widespread. 08:15.760 --> 08:22.760 And honestly, it has much better documentation about how you can embed it in your program. 08:22.760 --> 08:25.760 In this case, it's our component. 08:25.760 --> 08:31.760 Overall, the picture looks like this, so we have SQL Core, which has parser optimizer, 08:31.760 --> 08:37.760 data dictionary, data logging, subsystem, what not. 08:37.760 --> 08:43.760 We have storage engines here, below the SQL Core, 08:43.760 --> 08:48.760 and then we have service API, or component API. 08:48.760 --> 08:56.760 And then, which interacts with component, which manages JavaScript code, 08:56.760 --> 09:01.760 does some type conversions, provide some helper UGFs, 09:01.760 --> 09:09.760 so additional data is visible and accessible from the inside of SQL Core, 09:09.760 --> 09:10.760 and from mySQL. 09:10.760 --> 09:16.760 And basically what it does, it's ropes around the V8 library, 09:16.760 --> 09:21.760 which we use for JavaScript execution. 09:21.760 --> 09:27.760 And then V8 library has a such concept like a NizoLate, 09:27.760 --> 09:32.760 which is, you can say it's more or less a separate instance of V8 library, 09:32.760 --> 09:38.760 in which your data is stored, and your code is run, 09:38.760 --> 09:43.760 so each isolated is more or less isolated from each hour. 09:43.760 --> 09:48.760 You can't really easily pass, for example, memory from my NizoLate, 09:48.760 --> 09:52.760 so we use a isolated connection model. 09:52.760 --> 09:58.760 And if you have read the Oracle, Oracle's white papers about how we do 09:58.760 --> 10:03.760 support JavaScript, you may have seen pretty similar picture there, 10:03.760 --> 10:08.760 but it's no wonder because ultimately both hours component 10:08.760 --> 10:13.760 and various component are just a glue code between SQL Core 10:13.760 --> 10:17.760 and some JavaScript engine. 10:17.760 --> 10:22.760 And now in V8 it's V8, in V8, in V8, case it's柚. 10:22.760 --> 10:31.760 So, we support both functions and procedures, 10:31.760 --> 10:36.760 but not events are triggers, the same is upstream. 10:36.760 --> 10:45.760 Again, in out, in out parameters are supported for stored routines. 10:45.760 --> 10:53.760 We also support almost all SQL types as parameters or return values. 10:53.760 --> 10:56.760 I think we actually support more than Oracle. 10:56.760 --> 11:03.760 In this respect, we support parameters and return values and all character sets. 11:03.760 --> 11:09.760 Yes, internally JavaScript is totally UTIF8 and before. 11:09.760 --> 11:12.760 Well, UTIF8, but we do conversion for you. 11:12.760 --> 11:27.760 So, if you, for some reason, still do not use UTIF8, you still can write a routine and avoid using some additional code to do conversions. 11:27.760 --> 11:30.760 Then, according to JavaScript, you know, okay. 11:30.760 --> 11:41.760 We convert blobs to array, buffer objects, so you can manipulate with binary data in JavaScript easily. 11:41.760 --> 11:52.760 When I think of it's it, the level of GS language we support is the same as the recent stable V8 support. 11:52.760 --> 11:56.760 So, let's make sure since we rely on it. 11:56.760 --> 12:01.760 We have, although standard operators, data types, standard objects. 12:01.760 --> 12:04.760 For example, math object functions. 12:04.760 --> 12:09.760 We, of course, do not have any browser specific things, right, because we like DOM. 12:09.760 --> 12:15.760 We are provided by browser and an SQL server is simply do not have DOM. 12:15.760 --> 12:17.760 No point in it. 12:17.760 --> 12:21.760 We are also one design decision which you made. 12:21.760 --> 12:29.760 We are implementing a trusted language, which means that you are not supposed to be allowed to do anything from your JavaScript routine, 12:29.760 --> 12:34.760 which you cannot normally do from the SQL. 12:34.760 --> 12:38.760 We do not really allow any file access on it. 12:38.760 --> 12:44.760 Work access, for example, for example, we are available in Node, right. 12:44.760 --> 12:46.760 But we do not allow that. 12:46.760 --> 12:59.760 We might change that in the future, but we are a security trade-offs here, so it's worth thinking hard about it. 12:59.760 --> 13:02.760 So, that's a pretty simple example. 13:02.760 --> 13:14.760 If you haven't, especially maybe useful, if you haven't seen how JavaScript routines created in Oracle MySQL before, 13:14.760 --> 13:19.760 you just write create function, you specify language. 13:19.760 --> 13:26.760 One difference here is that in upstream the name of the language is JavaScript, we do not use this name. 13:26.760 --> 13:34.760 We use JS, as I have said, legal issues. 13:34.760 --> 13:49.760 And also, to be honest, it's nice when you have a support ticket and you can tell right away if it's something from the upstream or from on someone you see your component. 13:49.760 --> 13:58.760 Then there is this double-dore coating, which allows you to provide the text over JavaScript code after that. 13:58.760 --> 14:03.760 And you end up closing with double door as well. 14:03.760 --> 14:08.760 A mask-all command line client has support for this. 14:08.760 --> 14:12.760 A nice support for this double-dore coating. 14:12.760 --> 14:17.760 So you do not need to use this millimeter command. 14:17.760 --> 14:28.760 If it, as you can see, they're variable, the parameter for routine is available, 14:28.760 --> 14:32.760 just as usual JavaScript variable inside of JavaScript code. 14:32.760 --> 14:33.760 And you can use it. 14:33.760 --> 14:37.760 When you just use it like a normal story function, 14:37.760 --> 14:44.760 if you will have time, we will do a bit small demo at the end. 14:44.760 --> 14:48.760 So what's the current statusal project? 14:48.760 --> 14:51.760 It's in the public page preview. 14:51.760 --> 14:59.760 It's a separate branch of Percona server based on eight-four LTS. 14:59.760 --> 15:02.760 Code is available on GitHub. 15:02.760 --> 15:06.760 We do not have binaries yet, 15:06.760 --> 15:10.760 but we do plan to have in this quarter. 15:10.760 --> 15:15.760 It's quite possible to build it yourself. 15:15.760 --> 15:21.760 Actually, in my opinion, the main complication is building V8, actually, where. 15:21.760 --> 15:28.760 And the build instructions are available in the company's Redmi, MG file. 15:28.760 --> 15:29.760 You can try it. 15:29.760 --> 15:30.760 Yes? 15:30.760 --> 15:34.760 I also plan in other languages. 15:34.760 --> 15:37.760 It's a good question. Maybe at some point. 15:37.760 --> 15:41.760 But there are quite some work to do with JavaScript. 15:41.760 --> 15:44.760 Actually, let me show you in the next slide. 15:44.760 --> 15:49.760 So what's available now in V3? 15:49.760 --> 15:54.760 The support story program creation, dropping and execution. 15:54.760 --> 15:59.760 We do all these type conditions, which I mentioned. 15:59.760 --> 16:01.760 We support some advanced error. 16:01.760 --> 16:08.760 I think you can get, for example, a stack for your latest error in the JavaScript code. 16:08.760 --> 16:14.760 It works with, you can kill JavaScript procedure like a normal SQL statement, 16:14.760 --> 16:19.760 a max execution timeout, works as well. 16:19.760 --> 16:22.760 What we plan to work in the nearest future, 16:22.760 --> 16:26.760 and actually have a internal prototype in which it works, 16:27.760 --> 16:32.760 but probably not of the same quality as what we available already. 16:32.760 --> 16:37.760 In GitHub, it's that console support, support for memory limits, 16:37.760 --> 16:44.760 and support for execution of SQL from your story program. 16:44.760 --> 16:50.760 So if we talk about differences between percolors, variant and upstream, 16:50.760 --> 16:53.760 the main difference is actually license. 16:53.760 --> 16:57.760 So percolors, one is free and open source, 16:57.760 --> 17:02.760 and upstream the implementation is enterprise of cloud only, 17:02.760 --> 17:05.760 and of course source is not available. 17:05.760 --> 17:10.760 I think it's self-actual is open source. 17:10.760 --> 17:16.760 And this way, I wasn't surprised if you did VA. 17:16.760 --> 17:19.760 But documentation. 17:19.760 --> 17:25.760 You should ask the code, and I don't think they were here at the Java future, 17:25.760 --> 17:30.760 but if they are not yours or to other languages, 17:30.760 --> 17:34.760 we have support for other languages. 17:34.760 --> 17:35.760 Okay. 17:35.760 --> 17:38.760 And you can ask the guys from canonical. 17:38.760 --> 17:42.760 They provide shell without the people to pay them. 17:42.760 --> 17:45.760 I don't request all of them. 17:46.760 --> 17:50.760 When you push that, and you're leaving as well, 17:50.760 --> 17:52.760 it's really a pain. 17:52.760 --> 17:54.760 Yeah, well, we build it. 17:54.760 --> 17:58.760 And actually, our build people are complaining about it. 17:58.760 --> 18:02.760 But that's certainly doable. 18:02.760 --> 18:07.760 I will talk actually a bit more about it, because how much then? 18:07.760 --> 18:09.760 You still have to touch these. 18:09.760 --> 18:11.760 Okay, fine. 18:11.760 --> 18:16.760 So, other differences that what upstream has it is, 18:16.760 --> 18:22.760 is 9x based, and what we have is going to be based on 8x4. 18:22.760 --> 18:25.760 We are not aiming for full compatibility, 18:25.760 --> 18:29.760 and I do not think it's really realistic, 18:29.760 --> 18:33.760 but we tried to be at least on par, feature wise. 18:33.760 --> 18:35.760 We have stream. 18:35.760 --> 18:38.760 There are slight difference in syntax. 18:39.760 --> 18:41.760 Language name is different. 18:41.760 --> 18:44.760 There's JavaScript. 18:44.760 --> 18:47.760 Some different option names. 18:47.760 --> 18:50.760 We have different parameter conversion rules, 18:50.760 --> 18:55.760 but that might actually be adjusted. 18:55.760 --> 18:58.760 We have more. 18:58.760 --> 19:01.760 Well, we have different auxiliary users. 19:01.760 --> 19:04.760 If you have looked at the upstream implementation, 19:04.760 --> 19:06.760 I think one or two, 19:06.760 --> 19:09.760 UDF's which do everything. 19:09.760 --> 19:11.760 Get the error lock, 19:11.760 --> 19:14.760 get the console lock, 19:14.760 --> 19:17.760 get the latest errors, something like that, 19:17.760 --> 19:19.760 and that's it. 19:19.760 --> 19:23.760 We split one into different UDF's. 19:23.760 --> 19:29.760 We also have one differences that there are between implementations 19:29.760 --> 19:32.760 between handle JavaScript context differently. 19:32.760 --> 19:36.760 I think upstream has JavaScript context for each call, 19:36.760 --> 19:38.760 which for us, 19:38.760 --> 19:42.760 it turned to be rather expensive, 19:42.760 --> 19:47.760 so we opted for JavaScript context for connection, actually. 19:47.760 --> 19:49.760 Not exactly for connection, 19:49.760 --> 19:52.760 but for each user, which executed in connection, 19:52.760 --> 19:55.760 you can have several users, actually. 19:55.760 --> 19:58.760 Active around the same time, 19:58.760 --> 20:04.760 and things to sweet story routines or views of our functionality. 20:04.760 --> 20:06.760 And we are catching up. 20:06.760 --> 20:10.760 And of course, we are still in public preview, 20:10.760 --> 20:13.760 so it's both a bad thing, 20:13.760 --> 20:17.760 and the good thing is that we probably less polish it 20:17.760 --> 20:20.760 when upstream, but on the other hand, 20:20.760 --> 20:23.760 we still have a place for involvement, 20:23.760 --> 20:26.760 and still are willing to do changes. 20:27.760 --> 20:30.760 So, challenges. 20:30.760 --> 20:36.760 Let me find a bit about both upstream and V8, actually. 20:36.760 --> 20:40.760 So, there are some changes related to upstream, 20:40.760 --> 20:45.760 which we encountered by developing with component. 20:45.760 --> 20:50.760 First one is that we didn't find some services. 20:50.760 --> 20:53.760 We needed in the upstream, one of them, for example, 20:53.760 --> 20:59.760 was for notifying component about what connection is killed. 20:59.760 --> 21:02.760 Yes, you can easily from the component, 21:02.760 --> 21:04.760 find out with, okay, 21:04.760 --> 21:07.760 this connection is killed or the current connection is killed, 21:07.760 --> 21:10.760 but there is no hook, which would be killed, 21:10.760 --> 21:13.760 called on the kill itself. 21:13.760 --> 21:15.760 And it's not always convenient. 21:15.760 --> 21:17.760 For example, for V8, it's not convenient, 21:17.760 --> 21:20.760 for Gralve, I'm with my different story. 21:21.760 --> 21:26.760 We found some bugs in the service implementations. 21:26.760 --> 21:29.760 We didn't manage to report them, 21:29.760 --> 21:34.760 because they actually will fix it in later releases. 21:34.760 --> 21:36.760 But at least during work on the prototype, 21:36.760 --> 21:39.760 we had some questions, and we had to investigate and fix. 21:39.760 --> 21:42.760 For ourselves. 21:42.760 --> 21:46.760 So, to solve these changes, 21:46.760 --> 21:49.760 we had to extend a skull core a bit, 21:49.760 --> 21:51.760 and also fix a bug. 21:51.760 --> 21:54.760 I think we had the couple of services. 21:54.760 --> 21:58.760 What happens to the context when we do switch user? 21:58.760 --> 22:00.760 You just use different contexts, 22:00.760 --> 22:02.760 and actually you also use different. 22:02.760 --> 22:03.760 You just use different. 22:03.760 --> 22:07.760 Yeah, we actually use different easily, even. 22:07.760 --> 22:11.760 So, from security standpoint, 22:11.760 --> 22:14.760 you cannot really pass any objects from one user to another, 22:14.760 --> 22:15.760 unless you do it, 22:15.760 --> 22:19.760 and do it, means explicitly, through routine parameters, for example. 22:19.760 --> 22:21.760 Just have curious, right? 22:21.760 --> 22:23.760 And what, how does it know that it's that, 22:23.760 --> 22:25.760 the raw changes are, or you, 22:25.760 --> 22:29.760 you are really, you are creating the new context from the first and last changes? 22:29.760 --> 22:31.760 Uh, essentially, when, uh, 22:31.760 --> 22:34.760 user, well, connection enters JavaScript, 22:34.760 --> 22:37.760 which, in VCheck, and the VCheck user, 22:37.760 --> 22:39.760 it is executed. 22:39.760 --> 22:43.760 And if it's a new user, we create a new context. 22:43.760 --> 22:47.760 And there are also some changes related to V8. 22:47.760 --> 22:50.760 Uh, well, all of them, I would say, 22:50.760 --> 22:54.760 are related to the fact that the primary user of V8 is raw. 22:54.760 --> 22:56.760 So, we are very, very, very, 22:56.760 --> 22:57.760 raw oriented. 22:57.760 --> 23:01.760 Uh, we have this idea, is that, 23:01.760 --> 23:04.760 okay, people will be running, 23:04.760 --> 23:07.760 where JavaScript could probably separate process. 23:07.760 --> 23:10.760 Uh, and if, for example, 23:10.760 --> 23:14.760 we run out of memory, we will just crash the process. 23:14.760 --> 23:17.760 And people will, people will restart the working process, 23:17.760 --> 23:18.760 no problem. 23:18.760 --> 23:21.760 Obviously, that doesn't work well. 23:21.760 --> 23:24.760 So, we have to do some work grounds where, 23:24.760 --> 23:29.760 we tend to break things quite often. 23:29.760 --> 23:33.760 Uh, but they fix it on the other hand, 23:33.760 --> 23:35.760 but still, you find it, you, 23:35.760 --> 23:37.760 during the development of something is break, 23:37.760 --> 23:41.760 and you need to either to regard to adapt. 23:41.760 --> 23:44.760 And, uh, well, I guess the main problem is that, 23:44.760 --> 23:49.760 we also do not really follow with a stable model, 23:49.760 --> 23:52.760 uh, versioning model, right? 23:52.760 --> 23:55.760 When you have a minor versions, major versions, 23:55.760 --> 24:00.760 they do changes, using different considerations. 24:00.760 --> 24:03.760 Uh, okay, so, how can you help? 24:03.760 --> 24:05.760 Uh, please provide your feedback, 24:05.760 --> 24:07.760 especially if you are JavaScript developer, 24:07.760 --> 24:09.760 uh, because, uh, we, 24:09.760 --> 24:13.760 I personally do not have much expertise in JavaScript, for example. 24:13.760 --> 24:15.760 Uh, 24:15.760 --> 24:19.760 bug reports are welcome, uh, 24:19.760 --> 24:23.760 some feature requests are welcome, uh, 24:23.760 --> 24:26.760 documentation and proven surveillance are welcome. 24:26.760 --> 24:29.760 Uh, it's really easier to change things now 24:29.760 --> 24:32.760 in, uh, at the public previous stage when it, 24:32.760 --> 24:35.760 after it will become J, uh, 24:35.760 --> 24:38.760 we also set the hours on GitHub. 24:38.760 --> 24:40.760 Uh, 24:40.760 --> 24:42.760 so that's pretty much, 24:42.760 --> 24:44.760 cheat from the talk, 24:44.760 --> 24:46.760 and, uh, if we have, like, five minutes, 24:46.760 --> 24:48.760 we can, 24:48.760 --> 24:50.760 but, uh, two or three minutes here. 24:50.760 --> 24:52.760 Okay, so we can have a small demo against, 24:52.760 --> 24:54.760 how it works. 24:54.760 --> 24:56.760 Uh, so let's, uh, 24:56.760 --> 24:58.760 per corner server, 24:58.760 --> 25:00.760 just started up, 25:00.760 --> 25:03.760 uh, it's compiled with components we have, 25:03.760 --> 25:05.760 and they have some, 25:05.760 --> 25:08.760 scripted, uh, 25:08.760 --> 25:11.760 statements here, 25:11.760 --> 25:13.760 so first we need to install component, 25:13.760 --> 25:17.760 and when grant, uh, with special privileges, 25:17.760 --> 25:18.760 uh, 25:18.760 --> 25:21.760 okay, okay. 25:21.760 --> 25:25.760 Uh, special privilege to root user, 25:25.760 --> 25:28.760 so he can be, so he can create, uh, 25:28.760 --> 25:30.760 root in JavaScript, 25:30.760 --> 25:32.760 as you can see for seats, 25:32.760 --> 25:34.760 uh, 25:34.760 --> 25:37.760 then we can create, for example, 25:37.760 --> 25:39.760 a simple JavaScript function, 25:39.760 --> 25:41.760 which will use the standard, uh, 25:41.760 --> 25:43.760 JavaScript muff, 25:43.760 --> 25:47.760 library. 25:47.760 --> 25:52.760 So, here we create function, 25:52.760 --> 25:55.760 this is where, uh, 25:55.760 --> 25:57.760 JavaScript code, uh, 25:58.760 --> 26:00.760 muff with standard JavaScript, 26:00.760 --> 26:01.760 object, uh, 26:01.760 --> 26:02.760 silzy, 26:02.760 --> 26:04.760 32 is one of the standard functions, 26:04.760 --> 26:06.760 which find, uh, 26:06.760 --> 26:07.760 I think it's, 26:07.760 --> 26:09.760 left must use bit, 26:09.760 --> 26:10.760 something like that, 26:10.760 --> 26:12.760 and here we just, 26:12.760 --> 26:13.760 essentially provide the broader, 26:13.760 --> 26:16.760 around the standard JavaScript functionality. 26:16.760 --> 26:18.760 Uh, a bit more complex, 26:18.760 --> 26:21.760 example is, uh, 26:21.760 --> 26:24.760 maybe this, 26:25.760 --> 26:26.760 uh, 26:26.760 --> 26:28.760 it doesn't fit. 26:30.760 --> 26:33.760 Okay, let us skip it. 26:33.760 --> 26:34.760 Uh, 26:34.760 --> 26:36.760 so I also wanted to show, 26:36.760 --> 26:37.760 uh, 26:37.760 --> 26:40.760 the error reporting mechanism. 26:40.760 --> 26:55.760 So, you have some perhaps not, 26:55.760 --> 26:58.760 not very sensible JavaScript code here, 26:58.760 --> 27:00.760 which contains an error, 27:00.760 --> 27:01.760 you try to run it, 27:01.760 --> 27:02.760 uh, 27:02.760 --> 27:04.760 it returns an error to you, 27:04.760 --> 27:06.760 and you wonder what exactly happens, 27:06.760 --> 27:07.760 so you call, 27:08.760 --> 27:09.760 you give, 27:09.760 --> 27:10.760 which, uh, 27:10.760 --> 27:13.760 gives you extended context about error, 27:13.760 --> 27:14.760 uh, 27:14.760 --> 27:15.760 and essentially, 27:15.760 --> 27:17.760 shows the stack trace, 27:17.760 --> 27:19.760 where the error happened, 27:19.760 --> 27:21.760 and, uh, 27:21.760 --> 27:22.760 it's, 27:22.760 --> 27:23.760 it's, 27:23.760 --> 27:24.760 actually, 27:24.760 --> 27:25.760 shows exactly, 27:25.760 --> 27:26.760 positioning the code, 27:26.760 --> 27:27.760 the, 27:27.760 --> 27:28.760 where it's, 27:28.760 --> 27:29.760 has happened. 27:29.760 --> 27:30.760 Uh, 27:30.760 --> 27:32.760 but it's pretty much it, 27:32.760 --> 27:33.760 so we demo, 27:33.760 --> 27:35.760 so if you have questions, 27:36.760 --> 27:37.760 yeah, 27:37.760 --> 27:39.760 you mentioned there is no, 27:39.760 --> 27:40.760 five system access, 27:40.760 --> 27:42.760 but you also mentioned at the end, 27:42.760 --> 27:43.760 libraries, 27:43.760 --> 27:45.760 how do you bring in there? 27:45.760 --> 27:47.760 Uh, that's a very good question. 27:47.760 --> 27:49.760 Uh, 27:49.760 --> 27:50.760 probably like, 27:50.760 --> 27:51.760 uh, 27:51.760 --> 27:52.760 in nine, 27:52.760 --> 27:53.760 four, 27:53.760 --> 27:54.760 is it nine, 27:54.760 --> 27:55.760 four, 27:55.760 --> 27:56.760 which was most recently released, 27:56.760 --> 27:57.760 essentially, 27:57.760 --> 27:58.760 in the, 27:58.760 --> 27:59.760 in the latest, 27:59.760 --> 28:00.760 in, 28:00.760 --> 28:01.760 in, 28:01.760 --> 28:02.760 in, 28:02.760 --> 28:03.760 in, 28:03.760 --> 28:04.760 in, 28:04.760 --> 28:06.760 uh, libraries, 28:06.760 --> 28:07.760 uh, 28:07.760 --> 28:09.760 so one can, 28:09.760 --> 28:11.760 at library, 28:11.760 --> 28:12.760 yeah, 28:12.760 --> 28:13.760 uh, 28:13.760 --> 28:14.760 you do not really, 28:14.760 --> 28:15.760 you know, 28:15.760 --> 28:16.760 import existing, 28:16.760 --> 28:17.760 a library, 28:17.760 --> 28:18.760 a formal five system, 28:18.760 --> 28:19.760 in the very case, 28:19.760 --> 28:20.760 you create, 28:20.760 --> 28:21.760 you create, 28:21.760 --> 28:22.760 create model, 28:22.760 --> 28:23.760 create library statements, 28:23.760 --> 28:24.760 something like that. 28:24.760 --> 28:25.760 Essentially, 28:25.760 --> 28:26.760 you, 28:26.760 --> 28:27.760 you, 28:27.760 --> 28:28.760 you create library, 28:28.760 --> 28:29.760 provide its body, 28:29.760 --> 28:32.760 and then the component can use it as a library. 28:32.760 --> 28:33.760 But yes, 28:33.760 --> 28:34.760 it's actually one of, 28:34.760 --> 28:36.760 uh, 28:36.760 --> 28:37.760 uh, 28:37.760 --> 28:38.760 to do things, 28:38.760 --> 28:39.760 which we have. 28:39.760 --> 28:40.760 I'm not sure we will go with that, 28:40.760 --> 28:41.760 the very upstream, 28:41.760 --> 28:42.760 has gone, 28:42.760 --> 28:43.760 because, 28:43.760 --> 28:44.760 uh, 28:44.760 --> 28:45.760 we have changed that dictionary for, 28:45.760 --> 28:46.760 to support it, 28:46.760 --> 28:47.760 and, 28:47.760 --> 28:48.760 uh, 28:48.760 --> 28:49.760 we probably would like to avoid it, 28:49.760 --> 28:50.760 but, 28:50.760 --> 28:52.760 we should see. 28:52.760 --> 28:53.760 Yes, 28:53.760 --> 28:54.760 there's no way to, 28:54.760 --> 28:55.760 sorry, 28:55.760 --> 28:56.760 but, 28:56.760 --> 28:57.760 uh, 28:57.760 --> 28:58.760 what is your, 28:58.760 --> 28:59.760 uh, 28:59.760 --> 29:01.760 over and over, 29:02.760 --> 29:05.760 well, 29:05.760 --> 29:08.760 if you do not use any JavaScript function, 29:08.760 --> 29:09.760 you do not, 29:09.760 --> 29:10.760 because, 29:10.760 --> 29:11.760 you say that, 29:11.760 --> 29:12.760 you, 29:12.760 --> 29:13.760 you, 29:13.760 --> 29:14.760 you, 29:14.760 --> 29:15.760 you, 29:15.760 --> 29:16.760 you, 29:16.760 --> 29:17.760 you, 29:17.760 --> 29:19.760 you call a JavaScript code, 29:19.760 --> 29:20.760 okay, 29:20.760 --> 29:21.760 under the new yours, 29:21.760 --> 29:22.760 user, 29:22.760 --> 29:23.760 in connection. 29:23.760 --> 29:25.760 So if you do not call a JavaScript code, 29:25.760 --> 29:26.760 nothing happens. 29:26.760 --> 29:27.760 So it's, 29:27.760 --> 29:28.760 uh, 29:28.760 --> 29:29.760 from this point of view, 29:29.760 --> 29:30.760 and if you do not use JavaScript, 29:30.760 --> 29:32.760 you don't have to enable the continent, 29:32.760 --> 29:34.760 in the ultimate case. 29:34.760 --> 29:35.760 Ah, yes, 29:35.760 --> 29:36.760 yes, 29:36.760 --> 29:37.760 um, 29:37.760 --> 29:38.760 there is no way to black, 29:38.760 --> 29:39.760 I can solve it, right? 29:39.760 --> 29:40.760 Really? 29:40.760 --> 29:41.760 A JavaScript console, 29:41.760 --> 29:42.760 is, 29:42.760 --> 29:43.760 is there a way to, 29:43.760 --> 29:45.760 to have a string of the, 29:45.760 --> 29:46.760 you know, 29:46.760 --> 29:47.760 if you do a console, 29:47.760 --> 29:48.760 but, 29:48.760 --> 29:49.760 you know, 29:49.760 --> 29:51.760 if you do a console, 29:51.760 --> 29:52.760 but, 29:52.760 --> 29:53.760 you know, 29:53.760 --> 29:54.760 uh, 29:54.760 --> 29:55.760 is there a way to, 29:55.760 --> 29:56.760 to connect, 29:56.760 --> 29:57.760 and that is dreaming, 29:57.760 --> 29:58.760 if, 29:58.760 --> 30:02.760 which gives you the access to whatever was printed to JavaScript console. 30:02.760 --> 30:06.760 Um, 30:06.760 --> 30:07.760 it's not a console, 30:07.760 --> 30:08.760 it's, 30:08.760 --> 30:09.760 uh, 30:09.760 --> 30:10.760 it's a separate thing, 30:10.760 --> 30:11.760 but, 30:11.760 --> 30:12.760 it's pretty much similar, 30:12.760 --> 30:13.760 you just do, 30:13.760 --> 30:14.760 select and, 30:14.760 --> 30:15.760 and so on. 30:15.760 --> 30:16.760 Uh, 30:16.760 --> 30:17.760 I think, 30:17.760 --> 30:18.760 in the first version, 30:18.760 --> 30:19.760 which we will have, 30:19.760 --> 30:20.760 in the test preview, 30:20.760 --> 30:21.760 it will be, 30:21.760 --> 30:22.760 uh, 30:22.760 --> 30:23.760 uh, 30:23.760 --> 30:24.760 all the same, 30:24.760 --> 30:25.760 so it's, 30:25.760 --> 30:26.760 to give you, 30:26.760 --> 30:28.760 which will give you access to the console contents, 30:28.760 --> 30:29.760 uh, 30:29.760 --> 30:30.760 but, 30:30.760 --> 30:31.760 I, 30:31.760 --> 30:32.760 I was thinking about supporting, 30:32.760 --> 30:33.760 like, 30:33.760 --> 30:34.760 or, 30:34.760 --> 30:35.760 or, 30:35.760 --> 30:36.760 or, 30:36.760 --> 30:37.760 or, 30:37.760 --> 30:38.760 or, 30:38.760 --> 30:39.760 or, 30:39.760 --> 30:40.760 or, 30:40.760 --> 30:41.760 or, 30:41.760 --> 30:42.760 or, 30:42.760 --> 30:43.760 or, 30:43.760 --> 30:44.760 or, 30:44.760 --> 30:45.760 or, 30:45.760 --> 30:46.760 or, 30:46.760 --> 30:47.760 or, 30:47.760 --> 30:48.760 or, 30:48.760 --> 30:49.760 or, 30:49.760 --> 30:50.760 or, 30:50.760 --> 30:51.760 or, 30:51.760 --> 30:52.760 or, 30:52.760 --> 30:54.760 or, 30:54.760 --> 30:55.760 or, 30:55.760 --> 30:59.760 or, 30:59.760 --> 31:04.760 pieces. 31:04.760 --> 31:05.760 It's, 31:05.760 --> 31:06.760 it's not even 31:06.760 --> 31:07.760 connection with kill, 31:07.760 --> 31:09.760 but the Java script execution 31:09.760 --> 31:10.760 in the connection. 31:10.760 --> 31:11.760 So what's, 31:11.760 --> 31:12.760 what's, 31:12.760 --> 31:13.760 what's, 31:13.760 --> 31:14.760 what's the execution of your webboarded, 31:14.760 --> 31:15.760 but, 31:15.760 --> 31:16.760 connection won't be killed itself, 31:16.760 --> 31:17.760 you can, 31:17.760 --> 31:19.760 or use the connection in, 31:19.760 --> 31:22.760 yeah. 31:22.760 --> 31:23.760 Okay. 31:23.760 --> 31:26.240 Good had a good day together.