[Xcb] about api changes

[Ian Osgood]

On Jul 10, 2007, at 9:01 AM, Jeremy A. Kolb wrote:

> On Tue, 10 Jul 2007, Thomas Hunger wrote:
>
>> Hello,
>>
>> I want to warm up this topic, at least for the changes which I'd like
>> to introduce for sure. No. 2 would break the current API! It would be
>> great if someone sees any problems/additions now. Then we would not
>> need to break the API again.
>>
>> 1) Remove the xxx_request_t structures from the headers. They are  
>> only
>>    needed internally to pack data for requests. The opcode-defines
>>    could go as well. Are they useful for anything?

They are useful for protocol dissectors and documentation as well as  
libxcb internals.

How about splitting them into a separate header file? This would be  
similar to how the current xlib and extension headers are split into  
<ext>.h and <ext>struct.h. These were probably all put into one  
header in XCB for expediency, so as not to have a third type of XSLT  
build in addition to "source" and "header".

>>
>> 2) New naming conventions in structs/replies. The field-names in
>>    replies and structs (e.g. nameLen-> name_len in xprint.xml). This
>>    could be solved in two ways: a) apply naming filter to all  
>> names or
>>    b) write them correctly in the xml files.
>>
>>    Solution b) has the advantage that in the case someone really  
>> needs
>>    a name which is not coherent with the naming convention, she could
>>    introduce it.
>>
>> Tom

If we choose solution b), then it would be nice for the XML parser to  
spit out warnings if it detects names that don't match our chosen  
naming standards. This would then be the same amount of work as a),  
so we might as well do a).

I think the idea was that our XML descriptions would allow us to put  
in symbols verbatim from written documentation (such as the printed X  
protocol references) and the parser would be powerful enough to  
transform those symbols into our chosen naming convention. So  
studlyCaps would auto-convert to xcb_studly_caps_t or XCB_STUDLY_CAPS  
etc. depending on what kind of object the symbol was describing.   
Bart, correct me if I'm wrong about this.

Ian