[xcb] Quick and dirty XCL

[Jamey Sharp]

On 09/11 01:09PM, Keith Packard wrote:
> To replace Xlib, you must provide an ABI compatible interface for all
> published Xlib APIs and datastructures, including the internal interfaces 
> published for extensions and other grotty bits.

That's my point. Current XCL is not completely Xlib ABI compatible,
because the extensions all write directly into the output queue in the
Display, which is a null pointer in XCL. This can't be fixed by
replacing functions because the extensions are using the GetReq family
of macros for this access. I think my proposal gives us a perfect ABI
clone by using all of existing Xlib to begin with. It means applications
could start mixing calls between Xlib and XCB next week.

> It's a lot more (and less) than that.  My goal is to completely replace
> Xlib on every machine with XCL+XCB.  I think this is the best way to build
> a transition scheme from Xlib to XCB:

I think this is orthogonal to my proposal.

I'm not saying we don't ever replace Xlib. But Xlib is... big. :)
Re-layering all of it on XCB is going to take a while. I'd like to see
results a little sooner than "a while".

> I see the alternative as a constant game of dual development; as long as 
> Xlib remains the predominant development target, new features will be 
> first implemented there and then ported to XCL/XCB at some later date; 
> that leaves XCL/XCB as second class libraries, which will make application 
> developers very reluctant to depend on them.

I'm also not suggesting dual development paths. Implementing five or six
functions and using LD_PRELOAD gives us a proof of concept.  If, at a
basic level, re-layering Xlib on XCB is really that simple, then surely
after testing this code we can commit it to the XFree86 Xlib
implementation. Boom, no more dual development.

> So, the first step is to build a library which can provide a libX11.so 
> which completely replaces the existing libX11.so for all applications.

I merely suggest that there are several ways to replace libX11.so, and
they don't all involve eliminating it right away.

> That means that XCL needs to use the existing Xlib Display
> structure...

Uh-huh.

> ...we can just take all of the existing Xlib code and just use it
> without any changes...

Uh-huh.

> My idea is to split the code into pieces...

Uh-huh.

> ...eventually the last XCL dependencies will be gone and the apps 
> can get rid of that library as well for a complete XCB-based application.

Uh-huh.

Yeah, we're not disagreeing here, Keith. :)

So. Do you still think I'm missing anything? Does my proposal at least
accomplish the limited set of goals I've set for it?
-- 
Jamey Sharp <jamey@sharp.ath.cx> - http://jamey.is.dreaming.org/