Project Athena - X Window System Users and Developers Conference, Day 2 [4/6]

[MUSIC PLAYING]

SCHEIFLER: Okay. The afternoon session I think will be a little more technical maybe than the morning session. I'm not saying that's good or bad. I'm just pointing out we're going to try and give you some amount of detail about version 11 from the protocol on up. Can everybody hear me?

AUDIENCE: No.

SCHEIFLER: Not very well. Okay. My name is Bob Schiefler. I'm from the Laboratory for Computer Science. I'll take this one opportunity to say, I'm not from Project Athena. So saying X was designed at Project Athena is not a complete statement.

Version 10-- I did most of the protocol design. Version 11-- there are lots of us. I'm not the sole person. There are lots of DEC people up there. The fact that there are DEK people was not a significant factor. Okay? I put myself in the watchdog position of saying, we're going to make sure that there are no DEC influences saying, we want to make the protocol look like our hardware or something like that. But the subject never came up. Okay? It was not a problem. That's not going to work there.

The latest version of the protocol will be available on or before January 23rd via anonymous FTP to zap. That file, if you can't get it that way, you can send me mail there. And I will honor those as I can. If you absolutely can't get it by mail, you can try and call me. But I hate paper.

AUDIENCE: Hey, wait a second.

SCHEIFLER: Too fast for you, eh? My phone number you probably already have if you kept any of the original announcements.

AUDIENCE: What's the date of the latest version?

SCHEIFLER: The date.

AUDIENCE: October? August?

SCHEIFLER: Of the current version or this version?

AUDIENCE: This version.

SCHEIFLER: This version will be January something. Okay? And it will be called something like "Nearly Released," meaning we doubt it will change again. Everybody got this?

AUDIENCE: No. [INAUDIBLE]

SCHEIFLER: Yes?

AUDIENCE: Whoa. Whoa. Whoa.

AUDIENCE: You have that one?

SCHEIFLER: A mic went on.

AUDIENCE: A mic?

SCHEIFLER: That should have happened this morning. Gee, now I can talk. Okay.

Important things to keep in mind. The protocol is "Mechanism, not Policy!"-- very important. The way we get everybody to agree on this is we push the religious wars up higher. Okay? And you'll also see in the toolkit stuff the same kind of thing-- "Mechanism, not Policy!" At some point, somebody's going to start fighting wars. But it's not going to be me, which is the important thing.

The other thing that's important is, what we're defining here is a core protocol that's extensible. Okay? Core is in two aspects. One is that we don't think it will ever change again. Okay? There's not going to be a Version 12 in the sense that there is a switch from Version 10 to Version 11. If there is a Version 12, it won't be me. Okay? You know, the hope is that we have enough agreement that this can last for a while.

Okay I'm going to dive in. I'm going to assume you basically understand Version 10. And I'm not going to explain what a window hierarchy is and what network transparency is. You'd better know that or you're going to miss some things. You won't miss lots of things, but you'll miss some things. I'm going to tell you what's different, what's new. Okay.

Resources-- an important thing that we get right in Version 11 that we did wrong in version 10 was who allocates resource IDs. In 10, it was done by the server. In 11, it's done by the client so that you avoid a round-trip. The allocation will be hidden by Xlib, so you don't have to worry about it. In Version 10, resources always went away. They were always tied to a connection. And they went away when the connection went away.

Now you can specify that they survive the connection close, meaning that xsetroot, when it wants to allocate two colors to the background tile and then exits, your two colors don't get freed on you and it changes to random colors again. So things like that ought to work, of having long-lived resources independent of their creator. I'm going to go fast. Okay? I've got a lot of ground to cover.

Windows-- we've added support for multiple screens. So a server can support many screens. There's no implied geometry. The assumption is that there is still just one keyboard and one pointing device. And exactly how the pointing device might move between screens is not something that's mandated by the protocol. You could decide to add an extension to switch it between, or have it sort of warp as you move fast, or slow, or whatever. It's not implied. There's no geometry.

There is now support for windows of different depth as opposed to having all windows be the same depth. So if you have a 24-bit frame buffer, you can say, I might support windows of 1, 4, 8, 12, 24 bits. Important things for there is, the amount of data you have to ship. If you're really trying to do a monochrome image on a 24-bit display, you don't really want to send 24-bit images across. And there's a better match with memory allocation for backing stores and those kinds of things.

Window classes-- there's still input-output windows like there always were-- the normal kinds of windows. There are now input-only windows, which replace the transparent windows that were in Version 10. The major difference here is, input-only windows you can't output to. Okay? It's illegal output to them. And they have no interaction with output windows, okay, whereas transparent windows still acted as funny clipping things. And we'll see later how clipping gets handled.

The class mechanism is extensible. So extensions-- you might want to come in and say, oh, I have this random new kind of class, I don't know, double-buffered windows or something. And they need special semantics for them. And so the kinds of classes are extensible.

Color I'm not going to say almost anything about because there's a follow-on talk that's going to talk more about it. There is no longer a single colormap. There are now any number of logical colormaps that some subset of which will map into hardware colormaps. And they're associated with windows so that you know which ones are associated with which colormaps. There are now-- this is a little overkill. I'll have to whisper.

Many colormap classes, though. And in Version 10, there was just pseudo-color. And now there is pseudo-color, meaning non-segmented colormap. There's gray-scale as a degenerate case. There's direct-color as a segmented colormap, true-color as no colormap, and static-color as a read-only colormap, as well as monochrome. Okay? So we support all those kinds of classes. And a server can support multiple kinds of classes in the same server. All right? So you can have direct-color windows and pseudo-color windows through their colormaps.

Window reconfiguration-- it's been cleaned up. Instead of having separate move, resize, restack operations, there's a single operation that allows you to do any combination of those all atomically. And you can also change the border width, which you couldn't do in Version 10. And this funny restriction about whenever you do something the window pops up to the top is gone. So you can combine these and say it stays in the same place, or it goes to the bottom, or goes to the top, or combinations.

Exposures-- we've come down off our hobby horse in some ways. There is now support for backing store. So you can request that your window have a backing store, meaning the server will retain the contents in some way. And you won't get exposure events as windows cover it and uncover it. In specifying the backing store, you can specify-- Jesus. Really going on and off this.

Is it me? Or is it-- you can specify which bit planes are important for the backing store. So again, if you decide you're going to build a 24-bit window, but you're really treating it as a monochrome window, you can say, I only need this bit plane saved for me, please. And fill the others with this constant value. And save virtual memory allocation.

You can also begin to play tricks now that you have backing store. You can say, well, I'm going to create a fairly large window with a backing store. And then I'm going to create a smaller parent window. Okay? And since backing store is actually to the whole window and not to what's visible, you can pan around without getting exposure events. So you can use this as a kind of pan mechanism or a viewport. We also support save-under, meaning I can say, for this window, please save the contents of any windows under me when I come up, okay, for like pop up menus.

Another exposure avoidance mechanism is the notion of gravity. You can say, when my window gets resized, I would like this region of my window, the contents to be preserved. Don't throw them away. Save them for me. And you can specify any of the nine primary compass points for saying the bit contents ought to remain with the same fixed offset from that compass point regardless of how my window gets resized. Okay?

Or you can say, keep them static, meaning their absolute position on the screen doesn't change. Or you can say forget them, which is the way it worked in Version 10-- throw them away and give me an exposure event. Similarly there's a similar mechanism for your children so you can say how they should move when you get resized.

And again, you can give the same compass points, or you can say absolute on the screen. Or you can say forget them, meaning unmap them whenever I get resized. And then I'll take care of resizing them, and moving them, and then mapping them again. And you get rid of this funny effect that you often see in current Version 10 things of you resize it and it's got 50 subwindows in it. And they all flash around. And then they settle. So both of those should be useful mechanisms.

Events-- multiple clients can now select for events on the same window. And when they do, the event gets broadcast to all of them. Event propagation now only applies to device events, not to all events. And there's a mask in each window that says which device events should not propagate up the tree. So if you want to protect your superiors from knowledge, you can turn off device propagation. So you can say, I'm not interested in this event. But my parents shouldn't be interested in it either.

There are a couple of new classes of events of interest to various kinds of applications. There is structure notify, which says, I want to know via an event any time I get reconfigured in any way-- if I get moved, if I get unmapped, if I get mapped, if I get destroyed, resized, all those things you can get notified about. A number of those you couldn't find out about in Version 10-- for example, being moved.

If you want to protect yourself in some ways between-- if you want to get an adversary relationship with your window manager-- you can say, if somebody other than me tries to resize me, don't let it happen. Send me an event instead. And I'll take care of it. I'll be a responsible citizen. And I may twiddle it a little bit, but I'll resize myself the way you asked. Again this has to do with windows that have lots of say subwindows or contents that they want to somehow manage before they get resized rather than after they get resized.

You can also find out about changes in visibility. So now you can find out when your window becomes partially obscured, or fully obscured, or completely unobscured. So if you want to, for example, decide to stop output or input or something based on that, you can do it.

There are a number of hooks for window managers. And we spent a lot of time trying to figure out how to support all the kinds of window managers that people wanted to build, at least the ones that people talked to us about them wanting to build. An important thing for tiling window managers is one, being able to notice changes in configuration of subwindows.

So a window manager might select on the root window saying, tell me any time any first-level child changes, okay, like a new child gets created. Or an existing child gets destroyed. Okay? Sometimes the window managers will want that information to keep track of it rather than having to continuously pull or re-get the state every time they want to do something. They can keep a consistent state of what the top-level structure of the screen is.

They can also do a redirection similar to what a client can do for resize saying, for most kinds of configuration, if any child tries to reconfigure itself, don't let them do it. Send me an event instead. And I'll decide whether it's proper and right for them to do it. There are certain things that can't be redirected, in particular creation, unmap, and destroy. Those are things that the client can do at any time. But you can redirect things like move, and resize, and map, which are key things that a tiling window manager needs to have control over.

However when you get the pop-up menus, you want the pop-up menu to say, I don't care what kind of window manager is running. I don't want this many to be tiled way over there and arbitrary size, right. So there's an attribute on the window called override-redirect that says, forget what the window manager wants. I know I'm playing fair. Do what I mean. Okay?

There's also now-- you can alter the hierarchy. You can reparent a window. You can say, pick up this hierarchy and this sub-piece of the hierarchy and move it over there. This has, for example, a window manager that wants to provide uniform title bars or complex border decorations around any window can simply create a new window, and then reparent the old one inside of it, and then draw all the title bars and border decorations in that new parent window. And this is completely invisible to the application.

There are a number of Version 10 hooks for things like the window name, and the icon, and what the resize hint to the window manager ought to be. All those things have been flushed in favor of a general property-less mechanism where you can say, I have this piece of data, and I want to call it this name, and attach it to this window. And you can have an agreement among window managers, for example, that says, the property named "Name" should have an interpretation on the data of being ASCII. And you can do similar kinds of things.

So there's a general mechanism there to allow window managers to communicate with each other. And in a subsequent talk there'll be more discussion about how it can be used between clients, as well. And there's an event associated with that. So you can tell when properties on a window get changed.

Inter-client communication is what will be in the next talk-- talking about properties, being able to send events, the notion of selections. And the one thing I want to point out is that cut buffers as in Version 10 have been gone because they're subsumed by the other mechanisms in Building.

And the pointer-- once called a mouse, now called the pointer because it's not necessarily a mouse-- is no longer just three buttons. You can have any number of buttons, at most five of which are reported in device events. So you can only have instantaneous state on five. But otherwise, you can interact with any number of them. You get events for all of them. And you can grab them and so on.

In the area of motion events, you can now say, I only want motion events as a hint, meaning only send me one. And then don't send me any more until I query what the pointer position is. And this sort of corresponds directly to what lots of Version 10 applications were doing when they were tracking the mouse, which was exactly that-- using the motion event as a hint to wake up. And then they would just go pull the mouse and discard any motion events that had come in between. So now you can do that and save the server the pain and suffering of having to shove all those events across the network.

The server has always been free to discard motion events and compact them as it saw fit. There is now a request that allows you to get more detailed motion information about a window. So the server maintained some amount of past history about very fine grain motion of the mouse. And you can say, between this time and this time, tell me all the mouse motion events related to this window and what the coordinates in this window were. So draw programs, although perhaps not as real time, at least can get the information.

The keyboard-- the number of modifiers has gone up from whatever it was-- four-- to eight, only three of which now have standard definitions-- Shift, CapsLock, and Control. And the other five can be mapped to whatever you like them, whatever you want them to be, whatever modifiers you happen to have on your particular keyboard. You can now query for the instantaneous state of the keyboard to figure out what all keys are up and what all keys are down.

And associated with that is the ability to ask for a new kind of event on the window saying, any time the pointer enters my window, or anytime the focus comes to my window, send me the keymap state at that point. So applications that want to use nonstandard modifiers or want to do chording applications won't have any race conditions. They'll know at that point before any real input happens what the full state of the keyboard is. Better talk fast.

Device mappings-- you can now, inside the server, change what the physical to logical mapping of buttons and keys is. And this then applies to all clients, rather than just the one who was using this key map file to change it locally. The advantage of that is that now when you remap things, like I want this to be the Shift key or something, it will actually work right with respect to grabs and other things in the server. So in most cases traditional use of Xkeymap of saying, I want the Greater Than key there on my LK201 should go away.

In grabs, grabs have been extended. So you can not only grab buttons and the pointer, but you can now also grab keys in the keyboard. For pointer grabs, there is now a confine-to window, meaning when the grab activates, warp the pointer inside the window if necessary. And don't allow it to escape that window until the grab deactivates.

The restriction on the hierarchy of saying within any ancestor chain, only one grab on a given button can be outstanding, has gone away into a hierarchy. So that the way event processing works is grabs go first from root down, and then window interest goes second, from bottom up. Okay? And if you think about it long enough, you decide it's the right thing. So a window manager might, for example, and we'll get to this. I've got an example right here. So we'll come to it.

Associated with grabs now is the ability to freeze the processing of device events. So you can do synchronization and avoid race conditions. And I'll give an example. Once you've frozen a device, the kinds of thaw modes are make it asynchronous again-- just let it go-- send one more event and then freeze again, or replay the last event and avoid the fact that I had grabbed it originally. Okay?

Now an example of that is, let's say you've got a manager that wants to take the first click on a window and use it to set the focus to that window. Okay? Well, what you would do is grab the button on that window and say, I want the pointer to freeze when it happens. Okay? At the down event, you'll get the down event and the pointer will have frozen. At that point, you can change the focus, and then you have a choice.

If you want the application to not see the click, then you can just thaw the device in asynchronous mode. And then you'll get the up event as part of the grab. And then things will go along jolly. If you actually want the click to also go to the application, then you can simply replay the event, meaning process the event again. Okay? But ignore the fact that I have a grab. Okay?

Now the application controlling that window may also have that button grab. And in that case, it's grab will activate next. Okay? And there may be a hierarchy of things going down through that, which may happen if you sort of have managers within managers. For example in a toolkit layer, it's conceivable that you may want the same kind of management within a window that a top level manager wants to have.

[WHISTLING]

I have to talk fast. Off-screen images-- pixmaps. You can now have off-screen images of multiple depths. The server can support various kinds of depths. They can now be drawn into, with all the normal graphics operations. Bitmaps have gone away. They're just pixmaps. And they have various depths. We have this new notion called a drawable, which is either pixmap or an input-output window.

Graphics have changed from being stateless to being state-based. So there's a new resource called a graphics context. It's not part of the drawable. When you issue a request, you give both a graphics context and a drawable. And we'll explain more about what a drawable is.

Once you have a graphics context, it can be used with any drawable of the same depth on the same screen. So when you create a graphics context, you say what kind of depth drawable you want and what screen it's for. Having state-based graphics allows faster server implementations because they're a better match with many kinds of hardware now coming out or already existing. Also having state-based minimizes bandwidth. Because there are now all these gazillions of options, as you'll see, that you don't have to pass every time. You just pass this resource identifier for it.

Having a graphics context also allows transparent extensions without applications necessarily having to notice the change everywhere and making incompatible changes. So, for example, if you want to add a coordinate transform, which as you'll see doesn't exist in the core graphics context, you can simply add an extension request that says, please add a coordinate transform to this GC. And then all your standard graphics operations will continue to function without having an extra argument.

One thing to note in terms of graphics context is one should assume, as is traditional in operating systems, that context switches are expensive. Okay? The idea is these are still mapping into hardware states. And any time you have to switch hardware states, you're going to have more logical things than physical things. Okay? And somebody's going to have to do this complex check to see what's changed, and update all the CSRs, and all that magic. So assuming that graphics contexts are free is not the right thing.

Kinds of graphics-- you can draw points. You can draw lines. All of these things are now Poly requests, meaning that you can give this arbitrary length list of them in a single request rather than having just Line or Point. Okay? You can give a list of points, a list of lines, a list of--

AUDIENCE: Can you give me--

SCHEIFLER: PolyLine means you give each successive vertex and it draws continuously. PolySegment means I'm just giving you individual line segments to draw; rectangles; filled rectangles; arcs given by a bounding box, a start angle, and an extent angle; filled arcs; filled polygons; and text. And I'll get back to text. What happened to XDraw? XDraw has disappeared from the protocol and will be provided as an Xlib routine on the application side to do the complex deep transformation when you think you need it.

Lines have postscript-style semantics. So the calligraphy in Version 10 went away in favor of real line width. There is cap style for the end points-- butt, round, projecting. And for those who still like to think in terms of not drawing the last point for single pixel lines, there's a not-last mode.

There's a join style, meaning that when, for example, your doing a polyline, for wide lines you want to know whether the joins should be-- how they should look. And you can specify mitered, round, and beveled.

And for line styles, there are solid lines, meaning a single color-- actually that's not quite true, we'll say; and dashes-- both on-off and double dashes-- alternating colors. And there's also, just like in postscript, a general dash array instead of this funny thing that was in Version 10, and a pixel offset into the dash array for telling how to start the dashes.

Filling-- the kinds of things you can-- the ways in which you can fill. You can fill with a solid pixel. You can fill with a tile. And you can stipple with a pixel. You can now alter the stipple tile origin without having to reconstruct-- rotate the tile in funny ways.

Filling applies uniformly to all graphics, okay, including lines. When you draw a wide line, you think of that as filling a polygon. Okay? And filling applies to it. Same with text. Text is viewed as stippling. So you can have tiled and funny text.

For polygons we support both the even-odd and the non-zero winding rules. And if you don't know what they are, then you probably don't care. And for an arc, you can fill either as a pie slice or you can fill according to the chord joining the two endpoints.

For clipping, you can now explicitly give an additional mask for clipping. And that can be specified either as a list of rectangles or as a bitmap. And, of course, if somebody wants trapezoids or something, they can add an extension request to specify the input side of what that looks like. And then the server can transform it to whatever it wants internally. Given a clipping mask, you can change the origin of it-- move it around within the drawable-- without having to shift the whole thing again.

So summary of what a graphics context contains-- and this is why you don't want these passed in every request. It's got the logic function in the plane mask, just like in Version 10; foreground and background pixels; the tile, and the stipple, and the origin for them; the line width, cap style, joint style, dash style, pattern, offset; all these things, okay, and the font.

It also includes the subwindow mode so that you can say, when I'm drawing to a window whether to clip according to the children, or actually draw through the children. And for things like BitBlt, whether BitBlt should generate exposure events is now an attribute of the graphics contracts rather than an attribute of the window.

BitBlt-- copy area has been generalized. So you can now do a between drawables rather than just within a drawable. They have to be the same depth. And they have to be on the same screen. And there is now a CopyPlane, which allows you to copy a single bit plane instead of all the bit planes. And that can be done across drawables of different depths, but still on the same screen.

Images-- the image ordering in terms of bit order, byte order, and padding requirements, are now controlled by the server and not by the protocol. Okay? This means that, on the Xlib client side, you have this slightly hairy problem of converting from one format to the other. Of course, you always had that. But now it's sort of n-squared or something, depending on how you think you want to use internally. But Xlib is going to support that kind of thing.

The important thing is, now you can actually generally do that on the fly as you transmit rather than having the server get the whole thing in place, and then have to do this in-place swap, which can be very expensive. When retrieving an image back out, you can now just get a subset of the planes instead of always getting all of the planes. So if you really know I only have this monochrome image and it happens to be a 24-bit display, you don't have to get three megabytes of data back.

Fonts-- fonts are finally the right thing, I think. You can draw in all of the four major directions-- left to right, right to left, bottom up, top down. Fonts have kerning information. There's support for large glyph sets like Japanese. Fonts have a property list, a numeric property list, rather than a general data property list. But it's very similar to the property list on windows, where you can specify additional optional information like what the spacing should be, the italic angle, the point size, the 37 properties the tech defines for mathematics fonts, whatever you like.

You can now ask the server to give you all the font names that match a given pattern, and also to retrieve those properties without actually creating them as resources and querying them to allow you to do reasonable font selection. And you can also set the font search path. And I'm close to done.

Text-- related to fonts. Okay? So when you do text, you now have both 8- and 16-bit characters. You can't mix in a request. You either use 8-bit text or 16-bit text. Within a given text request, you can do both motion along the baseline, and you can do font shifts. Okay? So you can basically, in general, do a whole line of text in a single request. The char pad and space pad randomness in Version 10 is gone in favor of general motion along the line.

And last, extensions. The idea is this is a core protocol. But it can be extended in lots and lots of ways that I'm sure we haven't possibly thought of yet. The idea for an extension is very simple. You say, server, do you have loaded extension mumble, okay, when mumble is just this random string.

And the server comes back and tells you yes or no basically. And if it tells you yes, then what it tells you is the base opcode for requests is here. And it's assumed to be contiguous after that-- all the opcodes assigned to that extension. And you get back-- if it wants to extend the kinds of events, you get back the base event code for it. If it wants additional errors, you get back the base error code.

The important thing about all of these is that they're dynamically assigned. The client doesn't know what they are until it queries and gets them back. Okay? So the idea is, a client is not bound to any given implementation. As long as the extension exists in all the servers, it should be able to determine dynamically what constant to add to all the opcodes and so on to get the right thing to happen.

The assumption is that an extension typically will have a single major opcode, and then lots of minor opcodes inside of it whose format we don't say anything about. But that's the idea, is that extensions should be fairly large-grain things like 3D graphics, which is an example that you'll hear about this afternoon. And that's all I wanted to say. So questions.

AUDIENCE: Do you have these summaries printed in the document that you hand out?

SCHEIFLER: We'll have these summaries printed. I don't. I would say if what you want to do is get the protocol document-- because you may say, that's too much. I don't want to read 50 pages. If you send me mail, I can send you the tech source to this if that will do you any good. As I say. I hate paper. And I haven't actually reproduced it.

AUDIENCE: Yeah, on that is the-- on that three-page Mobius protocol, can you send us the protocol?

SCHEIFLER: Summary of protocol changes.

AUDIENCE: So that four-page overview of V-11.

SCHEIFLER: Is that the thing you wrote?

AUDIENCE: No, [INAUDIBLE] wrote.

SCHEIFLER: Okay. It hasn't been updated. Maybe we'll get around to that.

AUDIENCE: Do you have any performance comparisons with previous [INAUDIBLE]?

SCHEIFLER: Are there any performance comparisons? This is a protocol. When the server implementation comes up, you can ask them that.

AUDIENCE: Okay.

SCHEIFLER: And I won't tell you what the answer is because they probably don't know.

AUDIENCE: It seems like a lot of graphic things end up with [INAUDIBLE] or [INAUDIBLE] or whatever. I noticed when I was reading the protocol for that that you have arcs [INAUDIBLE]. But you don't go any [INAUDIBLE].

SCHEIFLER: Mm hmm.

AUDIENCE: Do you have any notion for doing that? Or perhaps that's a postscript or whatever?

SCHEIFLER: There are two possibilities. Actually there are more than two. One possibility is they-- if you want those, you convert them into polylines before you ship them. And whether that's expensive depends on how often you're doing it and how big the polyline resulting you actually think is going to happen.

The alternative is if enough people think those kinds of curves are important, you can always define an extension that will do that transformation to a polyline, which is probably what you're going to end up doing ultimately. Okay? And do it in the server side. So it's really only a question of bandwidth. Okay? And whether bandwidth is important is going to depend on a lot of factors.

AUDIENCE: [INAUDIBLE] size.

SCHEIFLER: Sure. Well, it depends on whether you think you have shared libraries or not, right. See I don't think Unix anymore.

AUDIENCE: [INAUDIBLE] of the group tiles and [? clipping ?] behavior, which are [INAUDIBLE] with respect to [INAUDIBLE]. Is there any procedure here for querying and resolving?

SCHEIFLER: The question is-- right. The question is we haven't seen any detailed semantics about what line width and so on means. My belief is that the spec that you will see on January 23rd is fairly precise about what all that means. And if it isn't, send me mail. Call me up. One or two more.

AUDIENCE: I saw that you were talking bit ordering and such. But could you do it on the more macro level that the expert [? in tiling kind of ?] [INAUDIBLE] 32-bit machine for its packaging request. It tops everything at 32-bit boundaries, something that's not like you've been doing there.

SCHEIFLER: It is still basically aligned on 32-bit boundaries.

AUDIENCE: So there's no way to change that.

SCHEIFLER: No.

AUDIENCE: Major [INAUDIBLE].

SCHEIFLER: What? You'll be the last.

AUDIENCE: Are there any extensions that have already been defined?

SCHEIFLER: Are there any extensions that have already been defined. There are a number of extensions that are in progress over which I have no control. And you'll hear about one of them today. I'm sure that there are others. I'm no longer in a position-- I mean, you have to realize now the cat is long out of the bag. Okay? MIT is no longer a focal point for what's going on in vendor world. Okay? So god only knows what they're doing.

AUDIENCE: What about reserved extension?

SCHEIFLER: There is no concept of a reserved extension.

AUDIENCE: [INAUDIBLE].

SCHEIFLER: Exactly. I mean, if you start to look at the verbiage of the press conference today, okay, the idea is, look guys. Okay, we've got ourselves a toehold now. But there are all these higher levels that we still have to standardize on. And there are all these things that the core protocol doesn't talk about that we still have to standardize on.

And one of the things we'll be talking about at the [? boff ?] on the protocol tomorrow is the beginnings of how do we start to tackle that problem. What kind of standards committee or whatever do we do if we're saying, I've got this wonderful extension. I want everybody to buy into it and consider it part of the core that everyone should assume exists.

I think I'm going to defer more questions. And there'll be Q&A at the end of the day. And people can ask more questions.

[APPLAUSE]

CARLTON: Sure. I'm Bill Carlton and I work for Digital. I have the dubious distinction of being the only person that was on the protocol design group to also be implementing the server. I'll be talking a little bit today about some of the mechanisms that were put in into X 11 to support interclient communication.

Now as Bob talked about before, this is all policy free. I'll tell you what the mechanisms do. And for a couple of the things. I'll give you examples of how they might be used. This is not to say that they're limited in any way to be used that way. But I'll show you what we got.

Bob mentioned atoms. They're basically just strings. You pass them in. And we didn't want to have to pass in long ASCII strings all the time. We did things too expensive to compare. And so the server will map strings to unique IDs. And you can get the string name back if you care. And every time you give the same string, you get the same unique ID. And that's convenient.

The server has no semantic values for any of the atom names whatsoever. They're totally up to the clients to agree upon what they're going to do with that. Atoms are used in various ways in the server. One of them is for naming properties. A property's just a bunch of bytes. And you stick it on a window. And there it is. It's got a type. It's also named by an atom. And so you can stick properties on your window or somebody else's window. And now you need some mechanism to let them know that that atom exists.

And so what you can do is you can send an event. And just like there all the events-- the extension events and the core events-- that can get sent from the server to any window, any client. You can-- any client can send any event to some other client. The server clips a bit on in the event to let the receiving client know that this was not necessarily generated by the server. And Maybe they want to watch out. Your choice.

There's one event that's never generated by the server. And its code name is InterpretNotify. And this mechanism allows you to set an event to your client, to any client, any window. And you can tell it some information, like where-- it's intended what you do is you stick a property over in some window under some name. And you send an event to the other client, to the window. And when it gets it, it gets this InterpretNotify event. And inside that it says, where did you put the property? Because he probably wants to go get the value. Because that's what you're trying to send to him. You tell him what the name of the property is. So he can also find that.

And you tell him what you want to do with it. For instance, if you stuck a property onto somebody else's window and sent them an event that said, please insert this text at this property that you'll find in your current input focus or your current insertion point. You could do that. Now to reiterate, the semantics of those atoms are totally up to the clients to agree upon. It's not the business of the server to be doing that. I'm supposed to say something else, but I forgot.

One more mechanism that was added is the notion of the selection. There are some user interfaces, and not all, that rely real heavily on the notion of a current selection. And so there's some support for that in the protocol. And the user thinks he owns the selection. Because he can see it highlighted on the screen in those kinds of user interfaces.

Actually in the protocol, the selection's owned by any particular window. And any window at any time can come along and say, I would like to be the owner of the selection. And then the server is nice enough to tell the old previous owner, you're no longer the owner. Please de-highlight your selection or whatever your semantics are. And go ahead and do that. And then the original application probably goes over and highlights the new selection.

The reason the word "the" here is it's not actually exactly one selection. There are some user interfaces have the notion of a primary and a secondary selection. And we didn't know. And then probably somebody out there with a tertiary and so on selections-- and so selections are named by atoms. So you want to become the owner of the primary selection. But it's up to you to choose the name, which is probably going to be primary.

So you say, I would like to be the owner of the primary selection. You hand in a window handle. And you're the owner. Notice no bites were transferred. The value of the selection is not transferred or anything like that. Somehow the owner of the selection's going to be told later that somebody else wants the value. And that gets done by a ConvertSelection call.

What happens is that some client sends a request to the server saying, please convert this selection-- the primary selections, for instance-- to text, or to a circle, or a Bezier curve, or whatever it wants. And we don't know. And what happens is that the server remembers who the owner of the current selection is and sends them a particular event called SelectionRequest.

And the owner of the selection takes that. And he figures out who it came from and has got all that information. And the intention is-- what it does is goes off to the guy who [INAUDIBLE] the requester's window, sticks a property on it, and sends an event to that guy saying, the data you asked for is there.

If the owner of the selection is unable to convert it, for instance, you ask somebody to convert the selection. And it happens to be the characters T-H-E to a circle. It might just say, sorry I couldn't do that and send an event saying, I couldn't do it. You can almost think of this as a request to the owner of the selection to send you an InterpretNotify. And there are a few other folks saying how you want to get it and why you want this thing.

And I thought I'd go through a very, very brief example of how the selection mechanism might be used. Oh, I remember what I was going to say about InterpretNotify. You probably all noticed that you could implement any kind of communications protocol you wanted to on top of that. It was not the intention by any of the designers or the implementers of the server that would be efficient or a wonderful thing to do. Whatever it is, go talk to the other client when you find out his name. And set up your own connection.

Here's the example. I'm going to posit that we have running on some server-- we have an editor running on some machine. And you're viewing some source code-- one of the favorite things that programmers like to do. And in some other window we have a debugger running. And the editor and the debugger don't know anything about each other. But they've agreed upon some semantics for particular atoms.

And so the user is sitting there. And he's looking at the source code. And he's got some line, a question he doesn't quite understand. And he selects the characters in the line somehow. He goes over to the debugger window and he hits the Set Breakpoint button. And the debugger doesn't know what to do. So it sends out a request to the owner of the current selection and says, please tell me the file name that's currently being viewed by in the window that owns the current selection.

And he gets back the answer, well, it's the famous Xclock program. And then he sends another request to him and says, hey, tell me what character position you are in the file. And he gets back, well, it's 512. And he looks in his fine grain table and says, well, that's going to be line 36. And it goes off and sets a breakpoint.

And it's done. And notice that the owner of the selection and the requester didn't know anything about each other. They're not necessarily running the same operating system. And they basically don't care. But they're still able to do the interclient communication using that mechanism.

That's it. Questions?

[APPLAUSE]