WEBVTT 00:00.000 --> 00:11.920 Okay, so presumably you're all here to listen to event driven X because if you're not, 00:11.920 --> 00:15.400 you're probably in the wrong room. 00:15.400 --> 00:16.560 Who am I? 00:16.560 --> 00:17.560 I am called Michael. 00:17.560 --> 00:19.520 I'm also called mouse. 00:19.520 --> 00:23.680 In computer context, the mouse name is probably better known. 00:23.680 --> 00:27.640 I've been to sort of like give some idea of my credit. 00:27.640 --> 00:30.960 I've been dabbling with X since the mid 80s. 00:30.960 --> 00:35.080 I think I used X10 briefly before X11 existed. 00:35.080 --> 00:39.760 I did the first two-bit gray scale server for the next hardware. 00:39.760 --> 00:44.720 I've done a DDX layer for the Sun CG 14 that puts 8 and 24 bits on the screen at the 00:44.720 --> 00:46.440 same time. 00:46.440 --> 00:49.560 I've done a bunch of other things that I don't want to go into too much detail on or 00:49.560 --> 00:53.640 still be here tomorrow. 00:53.640 --> 00:58.760 I would like to throw a shout out and thanks to Creadal, my primary work allegiance. 00:58.760 --> 01:02.760 This isn't a Creadal project that I'm talking about, but they are paying to get me to 01:02.760 --> 01:04.080 Faustin. 01:04.080 --> 01:07.880 So they deserve at least a thank you. 01:07.880 --> 01:16.480 So what it is, it's a CAPI to the X11 protocol. 01:16.480 --> 01:24.520 As far as I know, the only existing APIs for that for C are libX11, commonly known as X-Lib and 01:24.520 --> 01:28.320 XCB, which modern versions of X-Lib are built upon. 01:28.320 --> 01:32.040 This is completely independent to those. 01:32.040 --> 01:37.160 I've been, it's built on event-driven paradigms right from the ground up. 01:37.160 --> 01:44.240 I've been working on it for coming up on three years now, and the first question probably, 01:44.280 --> 01:49.000 many of you are thinking is, why am I still using X? 01:49.000 --> 01:53.400 And there are really three reasons, and very briefly you see them up there. 01:53.400 --> 01:57.080 One is that there's a huge installed base for X. 01:57.080 --> 02:03.440 One is that Wailing through a network transparency, and for many of my use cases, network 02:03.440 --> 02:06.880 transparency is not optional. 02:06.880 --> 02:11.960 And the third one is that as far as I know, Wailing is Linux only, and I do a good deal 02:11.960 --> 02:13.640 of non-linic stuff. 02:13.640 --> 02:18.000 I am very much a BSD person instead of a Linux person. 02:18.000 --> 02:22.520 So that's why I'm still caring about X. 02:22.520 --> 02:26.360 The whole thing is designed around callbacks. 02:26.360 --> 02:33.240 The goal, okay there, you can see it down near the bottom of the screen, but design goal 02:33.240 --> 02:37.360 is that the application should never block inside my library. 02:37.360 --> 02:41.920 If you do something that requires a round trip, like you get geometry request, then 02:41.960 --> 02:48.600 if you issue the request, you get back a handle, a pending request handle. 02:48.600 --> 02:52.520 And then using that handle, you can say, is it done yet? 02:52.520 --> 02:56.400 You can say, I don't care about hearing about it when it's done. 02:56.400 --> 03:00.240 You can say, I want to get a callback when it's done. 03:00.240 --> 03:04.520 And then if you really need that callback, if you really need that immediate notification, 03:04.520 --> 03:08.320 use the callback, and then the callback goes and fetches the results from where you 03:08.320 --> 03:11.600 told it to put them. 03:11.600 --> 03:18.640 It's most, of course, given the paradigm, it's most designed, it is a best fit for event 03:18.640 --> 03:23.320 driven programs, the kind of thing that spends almost all of its time waiting for something 03:23.320 --> 03:25.320 to happen. 03:25.320 --> 03:29.720 And when I say event driven in that sense, I'm not talking about just events coming from 03:29.720 --> 03:30.720 the X server. 03:30.720 --> 03:34.760 I'm also talking about things like this other network service that I've connected to 03:34.800 --> 03:42.920 sending me something, or a timer has expired, or whatever sort of event you want. 03:42.920 --> 03:48.720 And now down at the very bottom there, the never blocks ideal is almost achieved. 03:48.720 --> 03:52.320 There is one place I'm aware of where it isn't, and that is that when you're opening 03:52.320 --> 03:59.320 a new connection, if you have a host name in the res in the display string, it will call 03:59.320 --> 04:04.280 get editor info to look that up and get editor info can block waiting for DNS or other 04:04.280 --> 04:06.840 form of name to address resolution. 04:06.840 --> 04:10.280 I've been thinking about possibilities for that, and I've got a couple of ideas, but I haven't 04:10.280 --> 04:14.680 even tried implementing any of them yet. 04:14.680 --> 04:20.760 So now that you have a vague idea of the what, how about the why? 04:20.760 --> 04:24.760 It's an experiment at this point. 04:24.760 --> 04:30.400 I started writing it because there's an event driven infrastructure there in the second line, 04:30.400 --> 04:32.960 there you, sorry, I'm pointing at this wrong screen. 04:33.000 --> 04:36.720 The second item there, you can see lib aio. 04:36.720 --> 04:39.000 I'll talk about that more later. 04:39.000 --> 04:43.840 For the moment, the critical thing is that it's not the lib aio, any of you are familiar 04:43.840 --> 04:49.400 with unless you've been really following what I do, but it is an event driven infrastructure 04:49.400 --> 04:56.240 library, and I have written a bunch of programs that used it, and then some of those 04:56.240 --> 05:02.880 programs wanted to also use X, and I've done a few that used X lib, and it's always 05:02.880 --> 05:05.920 felt like a bit of a mismatch. 05:05.920 --> 05:12.480 So I decided, okay, let's try to do it writer, and for my purposes, this is writer, and 05:12.480 --> 05:18.520 I'm hoping that at least a few of you find it useful as well, but time will tell. 05:18.520 --> 05:24.200 In particular, the event loop, if you're trying to use X lib, the event loop is a little 05:24.200 --> 05:26.080 awkward. 05:26.080 --> 05:31.680 You need to depend on X connection number, being the only descriptor that X lib has 05:31.680 --> 05:38.480 open, which fortunately it is because other things depend on it, and you have to depend 05:38.480 --> 05:45.200 on the way the X library handles its events and responses queue. 05:45.200 --> 05:50.160 And errors, especially network connection errors, can be problematic. 05:50.160 --> 05:54.520 I have a terminal emulator that's written with X lib, and I have had the whole emulator 05:54.520 --> 06:01.520 crash when one network connection goes away, and so I wanted to do better than that. 06:01.520 --> 06:05.840 Now, X lib helps with some of these, but not much. 06:05.840 --> 06:10.120 It's really just a C binding to the protocol. 06:10.120 --> 06:17.520 It doesn't have all of the event driven infrastructure stuff, and this is mostly for me. 06:17.520 --> 06:19.960 I hope that at least a few of you agree with me. 06:19.960 --> 06:22.200 I don't like monocultures. 06:22.240 --> 06:29.800 So having only one or two very closely related C APIs to the X protocol bothers me. 06:29.800 --> 06:33.440 So I wanted to come up with another one. 06:33.440 --> 06:34.640 Why would you use it? 06:34.640 --> 06:39.480 Well, maybe you shouldn't, but why would you, why may be, would you? 06:39.480 --> 06:46.080 There are some use cases that's better fit for, like my time has gone away. 06:46.080 --> 06:51.240 Like, as I said, programs that spend almost all their time waiting for something to happen. 06:51.240 --> 06:57.000 If you've got events coming in from places other than the server, if your program is already 06:57.000 --> 07:02.720 structured around callbacks, then it can be more convenient sometimes to have all of the 07:02.720 --> 07:06.120 X stuff coming back as callbacks as well. 07:06.120 --> 07:12.200 It's closer to the protocol in some respects, and that respect it's like Xcb, and for 07:12.200 --> 07:16.760 some use cases, that's a good thing. 07:16.760 --> 07:23.480 And although it's probably not much of a big deal for most purposes, the licensing is 07:23.480 --> 07:25.200 compatible with everything. 07:25.200 --> 07:30.360 I've released a whole thing into the public domain, and my readmees say that in jurisdictions 07:30.360 --> 07:36.360 where I can't do that, it should be interpreted as whatever the closest to approximation 07:36.360 --> 07:40.200 that is available is. 07:40.200 --> 07:42.600 Why would you want to not use it? 07:43.160 --> 07:47.760 Well, for one thing, if your program isn't event driven, if you've got something that 07:47.760 --> 07:52.040 goes crunch crunch crunch crunch crunch on data, and every once in a while it puts up some 07:52.040 --> 07:56.480 sort of display, that is going to be a bad fit for my stuff. 07:56.480 --> 08:00.280 You'd be better off with X-labor or something like it in that case. 08:00.280 --> 08:05.560 If you've already got code, if you've already got a significant body of code that's 08:05.560 --> 08:10.960 written using X-labor Xcb, it is not easy to retrofit. 08:10.960 --> 08:14.120 You would have to rewrite it. 08:14.120 --> 08:17.440 If you don't want libio, there's that libio again. 08:17.440 --> 08:19.960 I've got a slide later, I'll talk more about it. 08:19.960 --> 08:25.480 If you don't want libio to own the event loop, then libio X will not be a good call for 08:25.480 --> 08:27.280 you. 08:27.280 --> 08:29.120 And as I said, it's still an experiment. 08:29.120 --> 08:36.160 It's still alpha quality, and in particular, extension support is very much in flux. 08:36.160 --> 08:37.600 It is usable. 08:37.600 --> 08:43.160 I've been thinking about how to implement some of the more problematic other extensions, 08:43.160 --> 08:49.840 but as yet, they are still ideas. 08:49.840 --> 08:55.680 Now I'm to the point of talking about libio, so what is it? 08:55.680 --> 08:58.480 It's the event-driven infrastructure that all of this is built on. 08:58.480 --> 09:04.800 It's depending on what you look at, one to two decades older than libio X, if you base 09:04.800 --> 09:09.360 it on the first commit in the Git repos, it's one decade older. 09:09.360 --> 09:17.200 But I can trace libio back, at least another decade, because I started out doing it as part 09:17.200 --> 09:20.680 of the implementation for something else, and then I stole that code and put it into 09:20.680 --> 09:21.680 another program. 09:21.680 --> 09:25.320 I stole it again for the third program and about five programs, and I said, this is silly. 09:25.320 --> 09:31.320 I should turn this into a library, so I did. 09:31.360 --> 09:37.200 It's completely unrelated to the Linux thing called libio, except for the coincidence of the name. 09:37.200 --> 09:41.560 So please don't get the two confused. 09:41.560 --> 09:46.760 It's basically in the same place as the live event, which those of you who have some BSD 09:46.760 --> 09:53.200 knowledge may know of, which of course raises the question why not use live event. 09:53.200 --> 09:56.160 And there are really three, three reasons. 09:56.160 --> 10:00.640 The first reason is that this started, as I said, it started as a small fragment of 10:00.640 --> 10:04.720 another program, which I pulled out and used somewhere else, pulled out and used somewhere else. 10:04.720 --> 10:09.160 And at the time I wasn't aware that libio event even existed. 10:09.160 --> 10:15.960 And now I still use it one because I've got a number of programs using it, but also I want 10:15.960 --> 10:19.840 to use this on some systems that don't have libivent. 10:19.840 --> 10:24.960 And third, there is some kind of mismatch between the way my mind works and the way libio 10:25.000 --> 10:29.560 events API is designed that makes it hard for me to grasp. 10:29.560 --> 10:32.160 So I've got something that works better for me. 10:32.160 --> 10:33.960 And if it works better for you, great. 10:33.960 --> 10:38.080 If libivent works better for you, then go with that. 10:38.080 --> 10:40.760 libio does expect to own the event loop. 10:40.760 --> 10:45.480 In that respect, it's like a bunch of other things. 10:45.480 --> 10:51.280 I've got some examples, I have a modest example here. 10:51.320 --> 10:55.680 These are some rudimentary web pages that I threw together because I'm not much of a web 10:55.680 --> 11:05.280 person, but that the first one is for a sort of software, including libio, libilex. 11:05.280 --> 11:07.840 And I think at least one or two other things. 11:07.840 --> 11:10.080 The bottom one is for libilex itself. 11:10.080 --> 11:15.040 And they're talk example that the T is being cut off by the display. 11:15.040 --> 11:25.040 But it's just a rudimentary little program that puts up a window with a yellow 11:25.040 --> 11:27.040 square stepping through it. 11:27.040 --> 11:31.440 And if you click on it, it draws a blue circle where you clicked. 11:31.440 --> 11:38.040 Fairly rudimentary program, the major point is that it's an example of a program written 11:38.040 --> 11:39.840 using libilex. 11:39.840 --> 11:41.040 I've got a few others. 11:41.040 --> 11:46.440 There are a couple of simple command line tools, one that generates WM delete window. 11:46.440 --> 11:50.040 One can't remember what the other one does off hand. 11:50.040 --> 11:53.840 But I've also done an SGF viewer for go games in it. 11:53.840 --> 11:59.240 And I'm in the process of putting together another simple game using it. 11:59.240 --> 12:06.040 So it is usable, although as yet, there are a number of issues with it. 12:06.040 --> 12:10.940 I mentioned extensions, the only extension that's really properly done is shape. 12:10.940 --> 12:14.140 And even that is just shape version one. 12:14.140 --> 12:22.140 I don't have any good, any servers handy that I can really test shape two against. 12:22.140 --> 12:28.640 And oh, sorry, I thought I thought I was on, I don't know which you people find more readable, 12:28.640 --> 12:33.140 probably this one. 12:33.140 --> 12:37.440 Okay, if you want to have more to do with it, how do you get it? 12:37.440 --> 12:43.440 My primary distribution mechanism is some publicly clonable get repose. 12:43.440 --> 12:45.640 And they're all my own infrastructure. 12:45.640 --> 12:49.340 That's why we've got GetRoman's Montreal or there. 12:49.340 --> 12:53.440 And now, so there's libile, there's libilex, and you may notice there, there's something else. 12:53.440 --> 12:55.640 LCS CVT. 12:55.640 --> 12:59.840 That is because this is written in slightly extended C. 12:59.840 --> 13:06.840 I added an extension to my C compiler to implement a form of labeling on control structures, 13:06.840 --> 13:11.040 so that things like breaks and continues can be associated with something other than the 13:11.040 --> 13:15.640 most smallest enclosing construct that they can apply to. 13:15.640 --> 13:22.840 And that, I'm not so sillier to think, all of you will immediately rush to pick up the modified compiler. 13:22.840 --> 13:30.740 So I have a program there that can run over.i files, the pre-processed code, 13:30.740 --> 13:35.740 to convert them into semantically equivalent things using go-toes. 13:35.740 --> 13:39.840 Not very human-friendly, but it is standard C. 13:39.840 --> 13:45.740 And at the moment, I can't remember whether I have distribution branches in the get repose 13:45.740 --> 13:49.640 that automatically run LCS CVT for you or not. 13:49.640 --> 13:54.340 If not, then I'm going to be doing that shortly after I get back home. 13:54.340 --> 13:58.840 If you just want to look at the code, instead of cloning the whole repo, 13:58.840 --> 14:05.440 then I export via both FTP and HTTP, an unpacked version of it. 14:05.440 --> 14:11.940 The version that ends just after the library name has the whole get-tree available. 14:11.940 --> 14:15.740 If you just want the working tree contents for the head, 14:15.740 --> 14:20.240 then just append slash head link slash tree to it. 14:20.240 --> 14:23.240 And if all else fails, you can send me mail. 14:23.240 --> 14:29.440 So all of those have been in cutoff at the left, the part before the hat is mouse. 14:29.440 --> 14:31.940 And as it says, there's my home address. 14:31.940 --> 14:36.440 I have a four-border address with a net BSD project. 14:36.440 --> 14:39.140 Again, creddle sent me to files them. 14:39.140 --> 14:41.940 And that's another plausible address for me. 14:41.940 --> 14:46.340 If you're sending through Gmail, then this one is really the only one that's likely to work. 14:46.340 --> 14:49.040 That's a different work address for me. 14:49.040 --> 14:55.840 And OK, so I'm running low on time, but I'm fortunately also running low on talk. 14:55.840 --> 15:00.040 OK, so that's sort of the once over. 15:00.040 --> 15:03.040 If anybody has anything they'd like to ask, I am listening. 15:03.040 --> 15:12.040 I think I saw a hand over there somewhere. 15:12.040 --> 15:13.040 Yes. 15:13.040 --> 15:21.040 My question would be, would like some more of the complex expansions to what the public. 15:21.040 --> 15:25.040 GLX would they be implementable? 15:25.040 --> 15:26.040 Probably. 15:26.040 --> 15:30.040 The question is, more complex extensions like, for example, GLX, 15:30.040 --> 15:32.040 how implementable are they? 15:32.040 --> 15:34.040 And they probably are. 15:34.040 --> 15:41.040 I haven't looked at GLX enough to know the internals, but I would expect that it's all fairly straightforward. 15:41.040 --> 15:49.040 It's either send stuff to the server or get back from the server and associate it with the response with the request that was sent. 15:49.040 --> 15:52.040 And that's the basic infrastructure. 15:52.040 --> 15:58.040 So something more complex like GLX, it's going to need a little more code, 15:58.040 --> 16:05.040 but it's probably not any hairier fundamentally than something like, say, get geometry. 16:05.040 --> 16:10.040 The most complex thing extension I'm aware of to implement is probably big requests. 16:10.040 --> 16:14.040 Because that needs hooks right into the packet parsing. 16:14.040 --> 16:17.040 The request and response parsing code. 16:17.040 --> 16:19.040 OK, I saw a hand over here. 16:19.040 --> 16:20.040 Yeah. 16:20.040 --> 16:22.040 This can be used to write finance or finance. 16:22.040 --> 16:25.040 Can you also be used to write the server side of it? 16:25.040 --> 16:29.040 The question is, can it be used for the server side as well or is it client only? 16:29.040 --> 16:32.040 At the moment, it is client only. 16:32.040 --> 16:37.040 It wouldn't be that difficult to build something analogous for the server. 16:37.040 --> 16:39.040 Would it be worthwhile? 16:39.040 --> 16:40.040 Maybe. 16:40.040 --> 16:45.040 If it turns out that GLX is a good match for how you want to build a server, 16:45.040 --> 16:49.040 then something like this would be appropriate. 16:49.040 --> 16:57.040 You basically just need to swap the generation and swap the parsing stuff for the generation stuff. 16:57.040 --> 17:02.040 So that you parse requests and generate responses instead of the other way around. 17:11.040 --> 17:15.040 OK, if anybody is interested in talking with me more about it, 17:15.040 --> 17:21.040 I expect to be available in the hallway track for probably basically the rest of the day. 17:21.040 --> 17:23.040 And creddle there. 17:23.040 --> 17:24.040 I mentioned them. 17:24.040 --> 17:27.040 They are basically my primary work allegiance. 17:27.040 --> 17:32.040 They are basically a head hunter crossed with consultancy governed as a cooperative. 17:32.040 --> 17:38.040 And if that sounds weird to you, then I can talk more about it in the hallway track. 17:38.040 --> 17:41.040 So, well, thank you very much. 17:41.040 --> 17:43.040 Thank you very much.