[Xcb] ANNOUNCE: XML-XCB project merging into XCB

[Josh Triplett]

This mail is to announce that my XML-XCB project
<http://linuxlab.cs.pdx.edu/~tripletj/xmlxcb> will shortly be merging
with XCB.  A description of my work on XML-XCB follows.  For review
purposes, the patch from XCB to XML-XCB is available at
<http://linuxlab.cs.pdx.edu/~tripletj/xmlxcb/xmlxcb.patch>.  The same
patch without new files included (to highlight the changes to the XCB
build system) is available at
<http://linuxlab.cs.pdx.edu/~tripletj/xmlxcb/xmlxcb-without-new-files.patch>.
A diff of the output is available at
<http://linuxlab.cs.pdx.edu/~tripletj/xmlxcb/xmlxcb-output.diff>, to
show that the changes to the output consist entirely of cosmetic
differences.  (Note that the diff excludes whitespace changes; also, to
avoid excessive noise in the diff, a change of the widely-used variable
name "parts" to "xcb_parts" was supressed by making the same change in
the "original" output files.)

I plan to merge these changes this weekend.

- Josh Triplett


XML-XCB Project Description
===========================

The XML-XCB project replaces XCB's M4-based protocol description
language and macros with an XML-based protocol description language and
an XSLT-based binding generator. This change has several advantages:

* XML and XSLT are much more widely understood than M4.

* There are many more tools that understand XML and XSLT.  Only the M4
  macro processor understands M4, and creating new operations based on
  the M4 protocol descriptions would require writing new sets of macros
  with the same API.  XML protocol descriptions simply provide
  structured data for use either by XSLT or by any programming language
  with an XML library.  This greatly reduces duplication of effort
  between different operations on the protocol descriptions.

* Bindings for different languages (whether native or just wrappers
  around the C API) would simply be additional XSLTs.  These XSLTs could
  generate the bindings directly, or output information for an existing
  language-binding generator.

* An automatically-generated server-side protocol handler would also be
  just another XSLT.

* Using the XML protocol descriptions, a program could analyze dumped X
  protocol streams and generate a listing of the X requests and results
  in that stream.  This analyzer would not need to be updated for each
  new extension (even one currently being developed), because it would
  use the XML protocol descriptions available to it at runtime in order
  to dissect the protocol stream.  Such an analyzer is currently in
  progress.

* Documentation for the X protocol could be embedded in the XML using an
  existing XML documentation format, or a subset or superset of such a
  format.  Protocol documentation could then be generated through XSLT,
  including API listings generated from the protocol descriptions
  themselves.


Architecture
============

XML-XCB consists of the following components:

* An XML Schema, defining an XML data format for X protocol
  descriptions.

* X protocol descriptions for the core X protocol and all extensions,
  written in the format defined by the XML schema.

* An XSL Transform (XSLT) to generate C bindings to the X protocol from
  the XML descriptions.  These bindings are implemented on top of the
  existing XCB transport layer.


Progress
========

Phase 1 - Summer 2004
Replacing XCB's protocol description mechanism with XML-XCB
-----------------------------------------------------------

I began by writing an XML Schema for XML-XCB, describing the data format
for the protocol descriptions.  I then converted one of the smaller
extensions, the DPMS extension, to the XML-XCB format, to provide some
sample data to work with.  At that point, I wrote the initial version of
the XSL Transform (XSLT) that translates XML-XCB protocol descriptions
into C bindings for the described protocol, built on top of the existing
XCB transport layer.

I then began the process of converting the protocol descriptions for the
remaining extensions, adding support in the XSLT and XML Schema for the
new constructs used by those extensions as needed.  Finally, I converted
the core protocol, and completed all remaining work on the XSLT in order
to reach feature parity with the existing XCB M4 macros.  At this point,
I could diff the output from XCB's M4 macros to that of XML-XCB, and see
no functional differences between the two.  As an additional check,
XML-XCB could also run all of the test programs in xcb-demo.


Phase 2 - Fall 2004
Enhancements Beyond XCB, and Merging into XCB
---------------------------------------------

After achieving feature parity with XCB during the summer, I then began
to work on an enhancement to XML-XCB beyond the current capabilities of
XCB.  I decided to work on full protocol descriptions for all of the
Freedesktop.org extensions, XFIXES, DAMAGE, Composite, and XEvIE.

Adding support for these extensions required many additions to the XSLT
binding generator, to support new features needed to describe these
extensions.  First, since several of the extensions referenced the data
structures of other extensions (most commonly those of XFIXES), I needed
a way for one extension to import the types declared by another.
Second, since one request in XFIXES has a variable-length list in its
reply that relies only on the reply length field in order to determine
the list length, I needed to add support in the XSLT for generating
expressions that reference the reply length.  This support was added in
parallel with adding a new feature included in the upstream XCB M4
macros: support for lists in requests that don't explicitly specify a
length expression, and have an implicit local field (not sent over the
wire) that specifies the list length.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : http://freedesktop.org/pipermail/xcb/attachments/20041105/b05b9778/signature.pgp