[Xorg] Extension extension

[Soeren Sandmann]

So I have been thinking about an extension-extension to reduce the
number of roundtrips during startup. I have discussed it a bit with
Adam Jackson (ajax on IRC).

Current state of affairs
========================

Clients initializes a lot of extensions and we should probably
expect them to initialize more in the future. Here is a list of
some popular extensions and the data clients immediately ask for:

BIG-REQUESTS
Everybody loves this extension because XLib initializes it
automatically and then immediately issues a BigReqestsEnable request.

MIT-SHM: 
Clients immediately sends MitShmQueryVersion which returns the version

XInputExtension
Two additional round-trips: GetExtensionVersion and ListInputDevices

RENDER:
QueryVersion , QueryPictFormats
        
XKB
XkbUseExtension


So it seems the adiitional data falls in two categories:

        GetVersionNumber

and
        
        QuerySomeData (which doesn't take any arguments)

Generally the data that clients query for (formats, devices, etc) is
needed before the client can go on using the extension.

So that's generally two to three round-trips per extension. This
write-up looks into ways of reducing that. There are several
possibilities, ranging from no server changes to many server changes:


Just Improve The Client Side
============================

There are things that could be done on the client side without any
server changes at all:

- Xlib

It would be possible to add a new call

        XQueryManyExtensions (Display *display, 
                              char **names, 
                              int n_names,
                              Bool *present)

to XLib that would send a lot of QueryExtension and return a list of
booleans indicating whether the extensions were present. In addition,
you could also imagine an

        XQueryVersions (char **names, int n_names, 
                        int *majors, int *minors)

that would return the version numbers of extensions that have them.
However all the extension specific data would still have to be queries
per extension, so the number of round-trips would still depend on the
number of extensions.

Within the framework of Xlib I don't think there is much more that can
be done without turning Xlib into an ad-hoc version of XCB. 

- XCB

With XCB, we can get down to three round-trips total:

        - Initial handshake
        - Send many QueryExtension
        - Send many QueryVersion, send many QueryData requests

Note that some of the queries for extension specific data might only be
available with certain versions of the extension. That doesn't have to
stop us from sending them; the client should just be prepared to handle
BadRequest errors.

If handling BadRequest errors is deemed too ugly, XCB can only get us
down to four round trips.


Adding a New META Extension
===========================

Xlib
----
Assuming we will still use Xlib, a new extension could improve on XCB
by one roundtrip. The extension could include a new request

        MetaQueryManyExtensions
                List of names
        ->
                List of ExtensionData

where ExtensionData is

        CARD32 MajorVersion
        CARD32 MinorVersion
        CARD32 DataLength
        CARD8  extension data

The extension data is specific to each extension. For example the RENDER
extension could send the list of supported formats. There would be a
client side API

        struct XMetaExtensionData
        {
                char *name;
                int major;
                int minor;
                void *data;
        }

        XMetaQueryManyExtensions (char **names, int n_names, 
                                  XMetaExtensionData *ext_data);

        XMetaFreeExtensionData (XMetaExtensionData *data);

And each extension would add calls like:

        PictFormat *
        XRenderGetPictFormats (XMetaExtensionData *data);

With this we could get down to three roundtrips:

        - Initial handshake
        - QueryExtension
        - MetaQueryExtensio

The big drawback here is that the META extension would have to know
about all other extensions, and all other extensions would have to
document what data they would send and how to interpret it. Also the
client side API is clumsy.

A different scheme, requiring more changes to the X server is:

        MetaQueryExtension
                STRING8         name
                CARD8           major_opcode
        ->
                BOOL            present
                CARD8           first_event
                CARD8           first_error
                CARD32          major_version
                CARD32          minor_version

        Error:
                BadOpcode

Ie., the client allocates the major_opcode for the extension. This would
have the big advantage that the client could then send extension
requests immediately provided it would be prepared to handle
BadRequests.

With XCB as the client API we would get down to three roundtrips:

        - Initial handshake
        - QueryExtension (for the META extension)
        - MetaQueryExtension + all the extension specific queries

In terms of number of roundtrips this is not an improvement, but the 
advantage in terms of elegance and generality is considerable. The
drawback is that substantial server changes would be needed to allow
client allocated major opcodes.

This extension could still be useful with Xlib():

        XMetaQueryManyExtensions (char **names, int n_names);

That would send all the QueryExtensions and a lot of common extension
queries. The data returned from those queries would then have to be
cached.

Finally,

Bumping the minor version number of the X protocol
==================================================

The most radical thing to do would be to bump the minor version number
of the X protocol and have the initial handshake include extension
negotiation.

Doing this would bring the number of roundtrips down to one, because
everything the client wanted to know would be in the initial data sent
by the X server. 

The drawback here is obvious: a new protocol version is a big thing that
should probably only happen if much other stuff would be fixed.


So, it seems to me that there isn't actaully much to be gained from
creating a new Meta extension. We can't really get below three
roundtrips wihtout changing the protocol, and on the other hand we _can_
get down to three roundtrips with just client side changes.


Søren