[Mono-list] [ANNOUNCE] Xnb: X protocol library for .NET

[Alp Toker]

I've started work on an X library written in C#. It's generated from the 
Xcb XML sources, so I thought it'd be appropriate to collaborate with 
the Xcb project on its development. Xnb is part of the NDesk project 
(http://www.ndesk.org/).

It doesn't actually work yet, but is nearing basic functionality. I'm 
announcing this early on because I have a few contributions to make and 
questions ask that may affect the design of Xnb.

You can check out the sources in Mono SVN (see http://www.go-mono.com/ 
for details), module xnb. Don't expect to see much, but the default make 
target will hopefully generate and build some 25,000 lines of X protocol 
helpers.

The library API is designed to look and feel like any other .NET API. It 
should work with any language that can target the CLR including Boo, 
Nemerle, VB, Python and a dozen more. It should also be possible to 
generate C GObject bindings for Xnb using the Mono 'cilc' tool which I 
maintain.

XCB
===

First of all, I've found a number of errors in the XML specs that should 
be integrated back into Xcb CVS. They were found using the mono-xmltool 
validator. You can get the fixed xml files in xnb/proto, and run the 
validator on them with 'make validate'. Hopefully, I'll eventually be 
able to exclude these files from Xnb SVN and use pkg-config to pull them 
out of the Xcb protocol package. There is still a validation error which 
shows up in glx.xml and xprint.xml: xcb.xsd does not permit the 
valueparam element within replies. Will leave fixing this one up to the 
Xcb developers.

DESIGN
======

Xnb has a fairly flat type hierarchy which tries to stay close to the X 
protocol without imposing decisions on the developer. XID-backed values 
are typesafe and checked at compile using implicitly castable structs 
(value types in the CLR) without the overhead of full objects. Casing is 
in the C# style, so CreateWindowRequest has the properties BorderWidth, 
Class, Depth etc.

IO is done using scatter gather IO vectors for performance, combined 
with lazy marshaling where necessary. Unsafe code is used to optimise IO 
where possible, with plans for fallback backends on high endian systems, 
Windows and 64-bit platforms with different memory layouts. The need to 
marshal will be reduced even further for common cases soon, and I expect 
performance to rival and exceed Xlib and even Xcb in certain cases.

INTEROP
=======

Xnb depends on Xcb to set up the connection right now, but this is only 
a temporary measure. I think it's pretty important for Xnb to maintain 
full compatibility with Xcb but I'd also like to make sure it can 
operate in "standalone mode", with no dependencies outside of the CLR. I 
have no particular desire to rewrite Cairo and would love nothing more 
than to be able to use the existing Mono.Cairo with Xcb backend, for 
example.

USES
====

Xnb could be used for:

	* Writing X applications, window managers, compositing managers
	* Writing "fun" X servers, say using Ajax and http
	* A porting layer to port X applications to other platforms
	* Profiling X applications and toolkits, in conjunction with Linux OProfile

ROADMAP
=======

Rewrite the generator cleanly
Get message passing to work in all cases, from both the client and 
server perspective
Implement X authentication using Mono crypto libraries, replacing Xau
Lose dependency on Xcb
Work out interoperability with Xcb
Decide whether to do latency hiding explicitly or implicitly
Consolidate X,Y pairs into Point, X,Y,Width,Height into Rectangle, 
Red,Green,Blue into Color etc.

In the mean time, I'd appreciate any comments on the design. Please go 
ahead and integrate the fixed XML files into Xcb CVS.

I'd also appreciate it if you could extend the schema and XML files to 
include information on how enums map to parameters. High level languages 
like C# provide features for typesafe enumerations, and it would be nice 
to maintain this information centrally in Xcb CVS rather than in a 
separate repository. Does this work for you?

Also, do you have any experience or thoughts on how Xnb might 
interoperate with Xcb?

Are there any plans to integrate documentation into the XML files, or 
for Xcb documentation in general? Xnb will need documentation too and 
there might be cause for collaboration.

(Note that the DNS record for this email address is updating. Please CC 
the list or find me on IRC with any questions over the next few days)