Am Mittwoch, 7. Februar 2007 20:51 schrieb Benjamin Franksen:
[...] XCB implements the full protocol (which already makes for a daunting amount of data types and routines). On top of that it implements a very lean connection management and request handling API that allows (this is one of the highlights) single-threaded as well as multi-threaded access.
Hmmm, the presentation in the paper is the other way round: The lower layer is the XCB_Connection layer, handling connections, requests and replies. On top of that, the XCB_Protocol layer implements, well, the protocol, including (un-)marshaling to/from C.
See the very readable paper http://www.linuxshowcase.org/2001/full_papers/massey/massey.pdf
After reading that paper and browsing around a bit, I think a slightly bolder approach might make sense for Haskell, in effect creating XHB ("X Protocol Haskell Binding"): I guess that the bulk of the code is in the XCB_Protocol layer, and that layer is already generated via an XML description for the C binding. If we can use the same technique to generate Haskell code, "only" a Haskell version of the connection layer would be needed to get a full XHB. This would have a few advantages: * There is no dependency on the XCB library, so XHB should work on *any* platform, including e.g. MinGW without any X11 libs. An X11 server is of course still needed... :-) * Data is only (un-)marshaled once. Using XCB, there would be 2 steps: Haskell <=> C <=> X protocol * The availability of protocol extensions is determined by XHB alone, not by any underlying XCB implementation. I am not sure if this is a realistic way to go, especially I am unsure about the amount of work needed to implement the functionality of the XCB_Connection layer directly in Haskell. Let's see if I can find a more or less stand-alone version of XCB (with no need to build all of X.Org) and understand how it is actually implemented. Any opinions? Hints? Cheers, S.