Sven Panne wrote:

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.

You're right, sorry for the confusion.

...

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 agree that this would be nice. (Disclaimer: I haven't the slightest clue about XSLT and how it is used to generate code from XML protocol descriptions. However, I assume this won't be that much harder than to find some method to 'auto-ffi' the huge XCB_Protocol API into Haskell.) Have you seen this: lists.freedesktop.org/archives/xcb/2006-January/001278.html ? The sources are here http://webcvs.freedesktop.org/xcb/xhsb/ It could be starting point, at least...

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.

Yes, this is going to be the most difficult part. I have taken a look at another XCB paper, which is about the XCB_Connection layer and explains how the problem has been modeled using the Z specification language (freedesktop.org/software/xcb/usenix-zxcb.pdf). Very interesting, this. I wonder if one could derive a Haskell solution (more or less) directly from the Z spec. Or, maybe, even simplify the spec, leveraging Haskell's more high-level interface to multithreading (STM?).

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.

Sources can be downloaded from the XCB site (a handful of tar.gz files). Build and install was rather uncomplicated here (debian/etch, amd64). Unfortunately, freedesktop.org seems to be down at the moment, so none of the above links will work until they are online again. Ben

Sven Panne wrote:

On Monday 12 February 2007 18:34, Benjamin Franksen wrote:

...

I agree that this would be nice. (Disclaimer: I haven't the slightest clue about XSLT and how it is used to generate code from XML protocol descriptions. However, I assume this won't be that much harder than to find some method to 'auto-ffi' the huge XCB_Protocol API into Haskell.)

The XSLT code to generate the C binding (c-client.xsl) is about 56kB. :-P Depending on the build system, personal preferences etc. it might make more sense to use Haskell code to transform the XML protocol description.

Yup. I didn't look at teh XSLT code before, but I have now: it looks awefully baroque. The /must/ be a simpler way, or at least a less verbose one.

...

Have you seen this:

lists.freedesktop.org/archives/xcb/2006-January/001278.html ? The sources are here http://webcvs.freedesktop.org/xcb/xhsb/ It could be starting point, at least...

The code needs some tweaks to make it compile and work with my local XCB library. Anyway, this is only a tiny hand-written demo, not a starting point for a project.

Ok; I haven't looked at it very closely.

...

Yes, this is going to be the most difficult part. I have taken a look at another XCB paper, which is about the XCB_Connection layer and explains how the problem has been modeled using the Z specification language (freedesktop.org/software/xcb/usenix-zxcb.pdf). Very interesting, this. I wonder if one could derive a Haskell solution (more or less) directly from the Z spec. Or, maybe, even simplify the spec, leveraging Haskell's more high-level interface to multithreading (STM?).

Ignoring Z for the moment, I've started to hack the connection layer for XHB, which seems to be feasible. Two problems:

* XCB depends on a handful XauFOO routines for authentication. It is not clear to me yet if we should do so in Haskell, too, or if we should re-implement that in Haskell, too. So for first tests no authentication will be offered. Welcome "xhost +"! ;-)

I agree that this can be postponed.

* Haskell's standard networking libraries are really, really awful: No IPv6 support, no getaddrinfo & friends, slightly obscure combination of features, one has to be careful about the byte order etc. etc. This has been mentioned several times already, but I don't know if there is currently anybody working actively on this. :-(

Using formal methods somehow would be nice, but there are more fundamental things waiting to be solved, as it seems...

From what I read in the ZXCB paper, the specification of the connection layer is somewhat tricky to implement correctly, at least when based on the semantics of Posix threads (and with the stated requirement for an API that can be used equally well for single and multi threaded clients). It could well be that an implementation in Haskell would have less problems with this aspect, and more with insufficient library support. Disclaimer: I haven't done any serious network programming in Haskell yet, so I'll have to take your word on this. And before I forget it, another one: I find this (potential) project very fascinating, but I doubt my Haskell programming abilities are good enough to contribute significant amounts of code to it.

Cheers Ben

On Tuesday 13 February 2007 14:15, Simon Marlow wrote:

This all seems reasonable if the goal is to provide an XCB layer in Haskell. But I have to ask the question: why? The only user of the X11 lib is HGL, and that's been ported to GtkHs now (ISTR), so who are the clients for an XCB layer? [...]

The conclusion of the above reasoning would be "rm -rf libraries/X11", but I wouldn't go that far... ;-) And similar arguments could be made for Win32. Anyway, I think there are a few reasons why something like XHB could make sense: * Fewer dependencies (no Xlib needed) * Automatic generation of almost all parts, leading to a very consistent API * Availability of dozens of protocol extensions for X11 for free, the X11 package has only the bare bones X11 * The possibility to use XHB in a multi-threaded setting (Xlib has only very arcane support for this, so everything is basically single-threaded) * Although Xlib will definitely stay with us for a long, long time, it seems to be a bit "deprecated". * The current X11 package needs a serious code review to fix the types. Apart from that, there are a few personal interests: * Improve my rusty XSLT skills * Test the available XML tools in/for Haskell * Get some ideas for a better networking package. BTW: What is the status of this? Is anybody already working on this? The current package has no clean layering, lacks most modern networking features, does a few things "behind the back" (which is often not what one wants), etc. Although I do not have enough time to push this actively, I would be very interested in joining such a "Let's build a better network package" task force... Cheers, S.

Simon Marlow wrote:

Sven Panne wrote:

...

On Tuesday 13 February 2007 14:15, Simon Marlow wrote:

...

This all seems reasonable if the goal is to provide an XCB layer in Haskell. But I have to ask the question: why? The only user of the X11 lib is HGL, and that's been ported to GtkHs now (ISTR), so who are the clients for an XCB layer? [...]

The conclusion of the above reasoning would be "rm -rf libraries/X11", but I wouldn't go that far... ;-) And similar arguments could be made for Win32. Anyway, I think there are a few reasons why something like XHB could make sense:

* Fewer dependencies (no Xlib needed)

* Automatic generation of almost all parts, leading to a very consistent API

* Availability of dozens of protocol extensions for X11 for free, the X11 package has only the bare bones X11

* The possibility to use XHB in a multi-threaded setting (Xlib has only very arcane support for this, so everything is basically single-threaded)

* Although Xlib will definitely stay with us for a long, long time, it seems to be a bit "deprecated".

* The current X11 package needs a serious code review to fix the types.

I think you misinterpreted me slightly: I didn't mean to ask "why XCB when we have an Xlib binding?", I'm asking "why do we need either?". Who is going to use it? Is someone planning to write a widget set in Haskell?

I think having an Xlib module is important; there's low-level stuff you might need to do in Xlib that isn't practical to do using GTK/Qt. Or you might want to build a light-weight application. Etc, etc.

Win32 is different: it is a layer used by the vast majority of Windows apps, because it encompasses not just the GUI but also the core OS services. X11, in contrast, is used by hardly any apps. I couldn't find anything in HackageDB that depends on it, apart from HGL.

...

Apart from that, there are a few personal interests:

* Improve my rusty XSLT skills

* Test the available XML tools in/for Haskell

* Get some ideas for a better networking package. BTW: What is the status of this? Is anybody already working on this? The current package has no clean layering, lacks most modern networking features, does a few things "behind the back" (which is often not what one wants), etc. Although I do not have enough time to push this actively, I would be very interested in joining such a "Let's build a better network package" task force...

Definitely with you there. Revamping network would be tremendously useful.

Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- -Rob Hoelz

Lennart Kolmodin wrote:

Rob Hoelz wrote:

...

Simon Marlow wrote:

...

I think you misinterpreted me slightly: I didn't mean to ask "why XCB when we have an Xlib binding?", I'm asking "why do we need either?". Who is going to use it? Is someone planning to write a widget set in Haskell?

I think having an Xlib module is important; there's low-level stuff you might need to do in Xlib that isn't practical to do using GTK/Qt. Or you might want to build a light-weight application. Etc, etc.

Or, rather, you want to write a window manager. This is already work in progress by sjanssen.

Those answer my question, thanks! SImon

On Saturday 17 February 2007 01:38, Jeremy Shaw wrote:

[...] ps. Some (minimal) Haskell GLX bindings and Example.hs can be found at:

http://www.n-heptane.com/nhlab/repos/haskell-glx/

Just a small note: One of the protocol extensions in XCB is GLX, so XHB would inherit this, of course. I don't have an idea how the GLX API will look like then, a thin "beauty layer" might be needed. Cheers, S.

Am Mittwoch, 7. Februar 2007 23:47 schrieb Duncan Coutts:

On Wed, 2007-02-07 at 15:17 +0100, Sven Panne wrote:

...

[...] * What about X11 implementations on *BSD, Solaris, AIX, HP-UX, etc.? [...] How about putting the Xlib binding into maintenance mode and moving the focus to XCB bindings.

I think this makes sense, at least if the OSes mentioned above will support XCB in the long run, too. Or do they already have support right now? It would be good to know that... Cheers, S.

Duncan Coutts wrote:

On Sat, 2007-02-10 at 13:09 +0100, Sven Panne wrote:

...

Am Mittwoch, 7. Februar 2007 23:47 schrieb Duncan Coutts:

...

On Wed, 2007-02-07 at 15:17 +0100, Sven Panne wrote:

...

[...] * What about X11 implementations on *BSD, Solaris, AIX, HP-UX, etc.? [...] How about putting the Xlib binding into maintenance mode and moving the focus to XCB bindings.

I think this makes sense, at least if the OSes mentioned above will support XCB in the long run, too. Or do they already have support right now? It would be good to know that...

Certainly Linux and Solaris use X.org. I can't remember if one or two of the BSDs still use XFree86 but the rest have moved to X.org. I have no idea about AIX or HP-UX.

HP-UX is dying fast. Anyway, a direct implementation of an X client library (an 'XHB', as Sven suggested, generated from XCB's language independent protocol description) would make these questions irrelevant. Ben