[Xcb] naming convention again ;)

[Jeremy A. Kolb]

On Mon, 12 Dec 2005, Jamey Sharp wrote:

> On Mon, Dec 12, 2005 at 04:31:06PM -0500, Jeremy A. Kolb wrote:
> > On Mon, 12 Dec 2005, Jamey Sharp wrote:
> > > If the name "data" were selected just because it makes Mesa code
> > > generation easy, I wouldn't approve. In that case you should load
> > > glx.xml from xcb-proto and look up the correct list name for each
> > > request: this is easy to do when you're already processing a bunch of
> > > XML anyway, and it's one of the big reasons why we built a protocol
> > > description language.
> > 
> > Ah yes.  The problem is that all of these replies have (roughly) 
> > the exact same format.  The fields had to be called data because there was no 
> > other way to autogenerate them from the glapi.xml file.  In X11 glx they 
> > use one structure to deal with all of these GLXSingleReply), and 
> > something similar when sending the request, we couldn't do the same in XCB.
> 
> I may still be confused, but I think you missed my point. When
> generating code for GetBooleanv from glapi.xml, why can't you do
> something like this XPath query across XCB's glx.xml?
> 	request[@name="GetBooleanv"]/reply/list/@name
> 

> That particular example will evaluate to "data" -- so you shouldn't have
> to hardcode that string anywhere.
> 

Oops. I think I missed your point then. What's an XPath query?

> > For example in GetBooleanv depending on retval you'll have different lists 
> > starting at different points in the padding.  If there is only one value 
> > to return it will be returned in pad4.  Since this is repeated for a ton 
> > of replies it was much easier to give consistent names.
> 
> We still need to deal with that, and I'd forgotten about it, but it's
> not related to reply list naming, right?

Right, I think I misunderstood (and still do) your post.  I had put that 
in because I thought it was relevant. :)

> 
> --Jamey
> 

Jeremy