[Xcb] OK, maybe API isn't *quite* stable... :-(

[Jamey Sharp]

On Wed, Dec 07, 2005 at 11:29:46PM -0800, Jamey Sharp wrote:
> This means that unless something unexpected happens, all code written to
> the API as implemented in CVS right now will both compile and run with
> XCB 1.0, whenever that is released. New functions may be added before
> then, but the current ones won't change.

Phooey. I think I have to take this back.

The core API can still probably be considered stable, though Bart has
raised an issue with XCBConnect under error conditions that we should
probably deal with.

However, the protocol-binding parts of the API, and perhaps the
extension API, need a little work yet. I have these pending issues that
I had forgotten:

The XCBGenericError** argument to cookie-forcing functions causes
unsolvable race conditions -- even a sort of race condition in
single-threaded applications. The problem is that if the application
looks for an event and then forces a cookie, whether in the same or
different threads, an X error might be returned by either call and you
can't predict which. I see two alternatives:
 * Pass XCBGenericError** to the request function, not the reply.
 * Drop the feature entirely.
Without this feature, application event loops have to coordinate with
all parts of the program that need to suppress or process error
responses; but even with this feature such coordination is required in
some cases, so I'm inclined to just drop the feature. This affects the
protocol and extension APIs.

The other issue is the awful naming convention. Getting names to have
sensible case is a matter of a little bit of XSLT work and a little
fixing of the protocol descriptions -- but porting existing code is
going to be a pain. Still, I think this is something we should do. I
know exactly what I was thinking when I picked the name
"XCBConnSetupSuccessRep", and it was really dumb.


Another issue that would be nice to address soon is exposing protocol
versioning in the API -- but I believe we can do that in a way that is
API-backwards-compatible later.

Implementing iovec-style, scatter-gather request functions will probably
change the XCBProtocolRequest structure and the XCBSendRequest function
in the extension API.

Can anyone think of anything else I've missed?

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20051212/0dac2f58/attachment.pgp