[Xcb] XCB/XCL

[Bart Massey]

Screwed up the e-mail address the first time.

	Bart

------- Forwarded Message

To: enlightenment-devel@lists.sourceforge.net
Cc: xcb@cs.pdx.edu
Subject: XCB/XCL
Date: Sun, 13 Apr 2003 03:29:26 -0700
From: Bart Massey <bart@bart.cs.pdx.edu>

Finally tracked down the thread Keith Packard mentioned
earlier about you folks' interest in XCB/XCL: somebody
linked the thread from /.  Thought it might be appropriate
to eagerly invite you all to participate in developing and
using XCB and/or XCL, and to (belatedly) answer a few of the
questions that came up in the discussion...


As was commented on earlier, XCB is a C library that speaks
X11 protocol out the bottom and provides a custom C API on
top.  Thus,

	client
	  ||   [c calls]
	  xcb
	  ||   [network/protocol]
	server

So far, looks like a silly idea: delete XLib + insert XCB.
But there are some reasons.

The one that might matter most to you folks is, as noted on
the list, latency hiding.  With Xlib, an X request like
XGetWindowProperty() which requires a response is executed
as

	1. client calls xlib
	2. xlib sends request to server
	3. xlib blocks (meaning client blocks) waiting for
	   response.  Much time may pass.
	4. xlib receives response from server
	5. xlib returns response to client

In XCB, it's 

	1. client calls xcb
	2. xcb sends request to server
	3. xcb returns a "cookie" to the
	   client labeled with the request.
	4. client gets back to work.
	5. some time later, the client needs the response
	   data.  the client now calls xcb to ask for the
	   response matching the cookie.  if xcb has
	   meanwhile received a response from the server,
	   xcb returns the response immediately.  otherwise,
	   xcb blocks until the response is received.
	6. xcb returns response to client

Thus, the client doesn't block until it needs the data.  In
particular, the client may send out many other requests,
including requests needing a reply, during step 4. 

The other stuff you get is mostly bonus here.  XCB is tiny
(about 35KB built from about 5K lines of C and M4), but
that's probably not so interesting to you.  If you switch to
a threaded model, you should need absolutely no changes to
your app for XCB---no locking, no magic variable decls, etc.


XCL sits atop XCB to provide the Xlib API to the client:

	client
	  ||   [xlib c calls]
          xcl
	  ||   [xcb c calls]
	  xcb
	  ||   [network/protocol]
	server

It's far from done yet, GetImage/PutImage being the most
glaring deficiency.  XCL is binary-compatible with Xlib: we
use LD_PRELOAD to run a few standard XFree86 client binaries
without Xlib.  The good news is that the XCB API is pretty
simple: for developers who have control over the source and
know what they're doing, XCL is probably a sidestep.

Deploying extensions such as SHM for XCB is really easy.
Essentially, we've crafted a metalanguage using the M4 macro
preprocessor: much of the C code is generated from
metalanguage description.  You type in some info about
opcodes, argument passing, etc, and you get out C code that
does the right thing.  This is all pretty well documented.


So what's the downside?

+ The project right now is Keith Packard + me, a college
  professor with a full time job doing other things + Jamey,
  a junior PSU undergraduate who wrote almost all the code
  and is heavily involved in other projects + Andy, a local
  high-school student who has contributed a bunch of pieces
  and helped a lot with documentation and debugging + maybe
  Keith and David, PSU grad students who would like to get
  involved but currently have no background.

  IOW, we need help.  The project will likely stagnate
  without more motivated and experienced developers.  It's a
  tiny project, and pretty well understood, so there's no
  huge effort to complete it.  Just the usual million little
  things like typing in and debugging the SHM extension :-).

+ There are functions of Xlib that are missing in XCB.
  Usually this is with good reason (used TekCMS lately?),
  but some of the pieces (e.g. a lot of caching) are
  intended to be provided by small separate libraries atop
  XCB and/or small hooks inside.  This work is fairly easy,
  but needs completing: see above.

+ You'd have to guinea-pig being the first major user, and
  probably someone would have to learn/know some M4.

If there's stuff we can do to help, we will.  As someone
noted on the list, we think that most toolkits and apps
using Xlib can move to XCB pretty easily and get a lot out
of it.  We're excited to help it move forward.


You can see the XCB/XCL web page and papers and mailing list
and whatnot at http://xcb.wiki.cs.pdx.edu/  Thanks again on
behalf of the XCB team for your interest.

	Bart Massey
	bart@cs.pdx.edu
	http://www.cs.pdx.edu/~bart

P.S. Najati, if you want to come to PSU for your Ph.D and
     work on XCB while you're here, drop me some e-mail :-).

------- End of Forwarded Message