Okay, so presumably you're all here to listen to event driven X because if you're not,
you're probably in the wrong room.
Who am I?
I am called Michael.
I'm also called mouse.
In computer context, the mouse name is probably better known.
I've been to sort of like give some idea of my credit.
I've been dabbling with X since the mid 80s.
I think I used X10 briefly before X11 existed.
I did the first two-bit gray scale server for the next hardware.
I've done a DDX layer for the Sun CG 14 that puts 8 and 24 bits on the screen at the
same time.
I've done a bunch of other things that I don't want to go into too much detail on or
still be here tomorrow.
I would like to throw a shout out and thanks to Creadal, my primary work allegiance.
This isn't a Creadal project that I'm talking about, but they are paying to get me to
Faustin.
So they deserve at least a thank you.
So what it is, it's a CAPI to the X11 protocol.
As far as I know, the only existing APIs for that for C are libX11, commonly known as X-Lib and
XCB, which modern versions of X-Lib are built upon.
This is completely independent to those.
I've been, it's built on event-driven paradigms right from the ground up.
I've been working on it for coming up on three years now, and the first question probably,
many of you are thinking is, why am I still using X?
And there are really three reasons, and very briefly you see them up there.
One is that there's a huge installed base for X.
One is that Wailing through a network transparency, and for many of my use cases, network
transparency is not optional.
And the third one is that as far as I know, Wailing is Linux only, and I do a good deal
of non-linic stuff.
I am very much a BSD person instead of a Linux person.
So that's why I'm still caring about X.
The whole thing is designed around callbacks.
The goal, okay there, you can see it down near the bottom of the screen, but design goal
is that the application should never block inside my library.
If you do something that requires a round trip, like you get geometry request, then
if you issue the request, you get back a handle, a pending request handle.
And then using that handle, you can say, is it done yet?
You can say, I don't care about hearing about it when it's done.
You can say, I want to get a callback when it's done.
And then if you really need that callback, if you really need that immediate notification,
use the callback, and then the callback goes and fetches the results from where you
told it to put them.
It's most, of course, given the paradigm, it's most designed, it is a best fit for event
driven programs, the kind of thing that spends almost all of its time waiting for something
to happen.
And when I say event driven in that sense, I'm not talking about just events coming from
the X server.
I'm also talking about things like this other network service that I've connected to
sending me something, or a timer has expired, or whatever sort of event you want.
And now down at the very bottom there, the never blocks ideal is almost achieved.
There is one place I'm aware of where it isn't, and that is that when you're opening
a new connection, if you have a host name in the res in the display string, it will call
get editor info to look that up and get editor info can block waiting for DNS or other
form of name to address resolution.
I've been thinking about possibilities for that, and I've got a couple of ideas, but I haven't
even tried implementing any of them yet.
So now that you have a vague idea of the what, how about the why?
It's an experiment at this point.
I started writing it because there's an event driven infrastructure there in the second line,
there you, sorry, I'm pointing at this wrong screen.
The second item there, you can see lib aio.
I'll talk about that more later.
For the moment, the critical thing is that it's not the lib aio, any of you are familiar
with unless you've been really following what I do, but it is an event driven infrastructure
library, and I have written a bunch of programs that used it, and then some of those
programs wanted to also use X, and I've done a few that used X lib, and it's always
felt like a bit of a mismatch.
So I decided, okay, let's try to do it writer, and for my purposes, this is writer, and
I'm hoping that at least a few of you find it useful as well, but time will tell.
In particular, the event loop, if you're trying to use X lib, the event loop is a little
awkward.
You need to depend on X connection number, being the only descriptor that X lib has
open, which fortunately it is because other things depend on it, and you have to depend
on the way the X library handles its events and responses queue.
And errors, especially network connection errors, can be problematic.
I have a terminal emulator that's written with X lib, and I have had the whole emulator
crash when one network connection goes away, and so I wanted to do better than that.
Now, X lib helps with some of these, but not much.
It's really just a C binding to the protocol.
It doesn't have all of the event driven infrastructure stuff, and this is mostly for me.
I hope that at least a few of you agree with me.
I don't like monocultures.
So having only one or two very closely related C APIs to the X protocol bothers me.
So I wanted to come up with another one.
Why would you use it?
Well, maybe you shouldn't, but why would you, why may be, would you?
There are some use cases that's better fit for, like my time has gone away.
Like, as I said, programs that spend almost all their time waiting for something to happen.
If you've got events coming in from places other than the server, if your program is already
structured around callbacks, then it can be more convenient sometimes to have all of the
X stuff coming back as callbacks as well.
It's closer to the protocol in some respects, and that respect it's like Xcb, and for
some use cases, that's a good thing.
And although it's probably not much of a big deal for most purposes, the licensing is
compatible with everything.
I've released a whole thing into the public domain, and my readmees say that in jurisdictions
where I can't do that, it should be interpreted as whatever the closest to approximation
that is available is.
Why would you want to not use it?
Well, for one thing, if your program isn't event driven, if you've got something that
goes crunch crunch crunch crunch crunch on data, and every once in a while it puts up some
sort of display, that is going to be a bad fit for my stuff.
You'd be better off with X-labor or something like it in that case.
If you've already got code, if you've already got a significant body of code that's
written using X-labor Xcb, it is not easy to retrofit.
You would have to rewrite it.
If you don't want libio, there's that libio again.
I've got a slide later, I'll talk more about it.
If you don't want libio to own the event loop, then libio X will not be a good call for
you.
And as I said, it's still an experiment.
It's still alpha quality, and in particular, extension support is very much in flux.
It is usable.
I've been thinking about how to implement some of the more problematic other extensions,
but as yet, they are still ideas.
Now I'm to the point of talking about libio, so what is it?
It's the event-driven infrastructure that all of this is built on.
It's depending on what you look at, one to two decades older than libio X, if you base
it on the first commit in the Git repos, it's one decade older.
But I can trace libio back, at least another decade, because I started out doing it as part
of the implementation for something else, and then I stole that code and put it into
another program.
I stole it again for the third program and about five programs, and I said, this is silly.
I should turn this into a library, so I did.
It's completely unrelated to the Linux thing called libio, except for the coincidence of the name.
So please don't get the two confused.
It's basically in the same place as the live event, which those of you who have some BSD
knowledge may know of, which of course raises the question why not use live event.
And there are really three, three reasons.
The first reason is that this started, as I said, it started as a small fragment of
another program, which I pulled out and used somewhere else, pulled out and used somewhere else.
And at the time I wasn't aware that libio event even existed.
And now I still use it one because I've got a number of programs using it, but also I want
to use this on some systems that don't have libivent.
And third, there is some kind of mismatch between the way my mind works and the way libio
events API is designed that makes it hard for me to grasp.
So I've got something that works better for me.
And if it works better for you, great.
If libivent works better for you, then go with that.
libio does expect to own the event loop.
In that respect, it's like a bunch of other things.
I've got some examples, I have a modest example here.
These are some rudimentary web pages that I threw together because I'm not much of a web
person, but that the first one is for a sort of software, including libio, libilex.
And I think at least one or two other things.
The bottom one is for libilex itself.
And they're talk example that the T is being cut off by the display.
But it's just a rudimentary little program that puts up a window with a yellow
square stepping through it.
And if you click on it, it draws a blue circle where you clicked.
Fairly rudimentary program, the major point is that it's an example of a program written
using libilex.
I've got a few others.
There are a couple of simple command line tools, one that generates WM delete window.
One can't remember what the other one does off hand.
But I've also done an SGF viewer for go games in it.
And I'm in the process of putting together another simple game using it.
So it is usable, although as yet, there are a number of issues with it.
I mentioned extensions, the only extension that's really properly done is shape.
And even that is just shape version one.
I don't have any good, any servers handy that I can really test shape two against.
And oh, sorry, I thought I thought I was on, I don't know which you people find more readable,
probably this one.
Okay, if you want to have more to do with it, how do you get it?
My primary distribution mechanism is some publicly clonable get repose.
And they're all my own infrastructure.
That's why we've got GetRoman's Montreal or there.
And now, so there's libile, there's libilex, and you may notice there, there's something else.
LCS CVT.
That is because this is written in slightly extended C.
I added an extension to my C compiler to implement a form of labeling on control structures,
so that things like breaks and continues can be associated with something other than the
most smallest enclosing construct that they can apply to.
And that, I'm not so sillier to think, all of you will immediately rush to pick up the modified compiler.
So I have a program there that can run over.i files, the pre-processed code,
to convert them into semantically equivalent things using go-toes.
Not very human-friendly, but it is standard C.
And at the moment, I can't remember whether I have distribution branches in the get repose
that automatically run LCS CVT for you or not.
If not, then I'm going to be doing that shortly after I get back home.
If you just want to look at the code, instead of cloning the whole repo,
then I export via both FTP and HTTP, an unpacked version of it.
The version that ends just after the library name has the whole get-tree available.
If you just want the working tree contents for the head,
then just append slash head link slash tree to it.
And if all else fails, you can send me mail.
So all of those have been in cutoff at the left, the part before the hat is mouse.
And as it says, there's my home address.
I have a four-border address with a net BSD project.
Again, creddle sent me to files them.
And that's another plausible address for me.
If you're sending through Gmail, then this one is really the only one that's likely to work.
That's a different work address for me.
And OK, so I'm running low on time, but I'm fortunately also running low on talk.
OK, so that's sort of the once over.
If anybody has anything they'd like to ask, I am listening.
I think I saw a hand over there somewhere.
Yes.
My question would be, would like some more of the complex expansions to what the public.
GLX would they be implementable?
Probably.
The question is, more complex extensions like, for example, GLX,
how implementable are they?
And they probably are.
I haven't looked at GLX enough to know the internals, but I would expect that it's all fairly straightforward.
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.
And that's the basic infrastructure.
So something more complex like GLX, it's going to need a little more code,
but it's probably not any hairier fundamentally than something like, say, get geometry.
The most complex thing extension I'm aware of to implement is probably big requests.
Because that needs hooks right into the packet parsing.
The request and response parsing code.
OK, I saw a hand over here.
Yeah.
This can be used to write finance or finance.
Can you also be used to write the server side of it?
The question is, can it be used for the server side as well or is it client only?
At the moment, it is client only.
It wouldn't be that difficult to build something analogous for the server.
Would it be worthwhile?
Maybe.
If it turns out that GLX is a good match for how you want to build a server,
then something like this would be appropriate.
You basically just need to swap the generation and swap the parsing stuff for the generation stuff.
So that you parse requests and generate responses instead of the other way around.
OK, if anybody is interested in talking with me more about it,
I expect to be available in the hallway track for probably basically the rest of the day.
And creddle there.
I mentioned them.
They are basically my primary work allegiance.
They are basically a head hunter crossed with consultancy governed as a cooperative.
And if that sounds weird to you, then I can talk more about it in the hallway track.
So, well, thank you very much.
Thank you very much.