[Xcb] bind from XML

[Josh Triplett]

Florent Monnier wrote:
>>>> I am not sure at all of this but perhaps it should be a little bit
>>>> more strict for OCaml users, for exemple switching to:
>>>>      <field type="WINDOW option" name="child" />
>> Except of course embedding ML type names is no good. It should clearly
>> be "Maybe WINDOW".
>>
>> /me starts a language war and runs away.
>>
>> But seriously, note that you should always be able to lift an integer
>> into a WINDOW, or else other bad things will happen. So the protocol
>> description as it stands doesn't prevent any valid programs from being
>> written.
>>
>> Also, having to parse type strings in the code generator is not good. So
>> some more XML-ish approach like those Ian proposes would be necessary,
>> and we won't wind up with either ML or Haskell syntax in the protocol
>> descriptions. :-)
> 
> Sorry I'm not so good in English so I'm not sure to understand everything.
> I really don't care if the key-words are something or something else.
> The ML style name was the first which came in my mind since I'm an every day 
> OCaml user :)

Of course; not a problem, and I understood just fine, having programmed
in OCaml a while back and remembered about the option type.

> I have seen that everything in the XML files is made for the C language since 
> every key words are C ones (enum, union, ...) and I really don't care of it.
> My question was only: could it be possible to make little enhancements to 
> bring it compatible with other languages than C ? since it seems (I'm not 
> sure yet) that it won't be descriptive enough for OCaml.

Most certainly.  If you believe that the XML files lack some information
needed in order to generate a language binding for another language,
please do suggest changes and/or patches to the list.  I very much
intended the XML-XCB protocol descriptions to serve for any language.

> What I've found interesting in your project was the goal to make it safer and 
> closer to the X protocol.
> What I have understood was that the X protocol should be universal/portable, 
> so perhaps there could be several parts in the code generation, a description 
> of the X protocol which is language independent, and then another XML file 
> which builds structures (for a specific language) from this first description
> and then the templates...

An interesting idea.  Technically true at the moment as well, since we
have XML protocol descriptions and an XML (XSLT) description of how to
build the structures for a specific language. :)  In general, I tend to
suspect that in most cases languages differ enough that we can't just
use a *data* file to describe their differences, and thus that we will
need a *program* to generate the bindings.  The binding generators could
certainly share much of their code, though.

> Well I guess this is an Utopia, and that I'm too much a dreamer :) since your 
> project is XCB where « C » stands for the C language.

Please don't think that. :)  The C in libXCB stands for the C language,
certainly, but when it comes to the protocol descriptions, we fully
indend them to work for any language.  My original project description
for XML-XCB stated as one of its benefits the ability to generate other
things from the protocol descriptions, including bindings for other
languages.  We would welcome a set of bindings for OCaml and any other
language, and we'd love to hear your thoughts on how the XML protocol
descriptions descriptions could further that goal.

>>> I'm not sure which XML constructs can best describe all these kinds
>>> of types.
>> A fairly traditional approach would use an attribute for the simplest
>> cases, but allow the use of a child element instead for more complex
>> ones.
>>
>> In CreateWindow:
>> <field type="WINDOW" name="wid" />
>>
>> In the KeyPress event:
>> <field name="child">
>>   <type>WINDOW</type>
>>   <const>0</type>
>> </field>
> s/const/type/ ?

As Jamey mentioned, s/type/const/.

>> Or, you know, something.
>  <field name="child">
>    <type name="WINDOW" />
>    <type name="0" />
>  </field>
> (IMHO attributes are often more easy to parse than PCData,
> it's only a personal point of view, maybe not shared with other peoples.)

I tend to prefer PCData in cases where:
1) the content feels more like data than metadata,
2) the attribute name adds no value, and
3) the element name alone accurately conveys the nature of the content.

All of the XML frameworks I've looked at (and I've looked at a number of
them) either provide equally easy access to element content and
attributes, or make it easier to get element contents.

Personally, I wish XML had originally just proclaimed the semantic
equivalence of <elem attr="foo" /> and <elem><attr>foo</attr></elem>,
and required parsers to provide them identically.

> The value 0 is confusing for other purpose than C, because in C a null pointer 
> can be made from the integer value 0, but in other languages 0 is strictly an 
> integer value and Null is something else.

To the best of my knowledge, nothing in the protocol passes a NULL in
the C pointer sense.  (Also note that in C, NULL == (void*)0, not 0.
This can matter a lot if sizeof(void*) != sizeof(int).)  In any case,
the protocol descriptions should provide constants for you to use
whenever they want a particular value with a particular meaning.

- Josh Triplett

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20060514/4845daf3/signature.pgp