[Xcb] Re: [E-devel] XCB/XCL

[Carsten Haitzler (The Rasterman)]

On Sat, 26 Apr 2003 14:05:57 -0700 Bart Massey <bart@cs.pdx.edu> babbled:

> OK, after dicussing with you and after long talks with Keith
> Packard and Jamey today, I think what we need is a tiny
> extension to XCB:
> 
>   XCBGenericResponse *XCBWaitResponse(XCBConnection *c)
>   XCBGenericResponse *XCBPollResponse(XCBConnection *c)
> 
> where an XCBGenericResponse is either an XCBGenericRep
> (consisting of reply data tagged by its sequence number), an
> XCBGenericError, or an XCBGenericEvent.  XCBPollResponse
> will return 0 if nothing is available, XCBWaitResponse will
> block (duh).  Once a cookie's reply has been returned by
> XCBPollResponse, the cookie becomes invalid for further use
> (duh).
> 
> I'm not sure who wants to write this bit: Jamey could
> probably do it in a few minutes (heh) or I could do it
> sometime next week, or someone else on XCB (Andy? David?
> Keith Miller?)  could try it, or you could try it.  Most of
> the needed bits seem to already be there.
> 
> I wanted to do something about tagging the returned reply
> with a request code or reply data type. The problem is that
> XCB has no internal queue for maintaining outstanding
> requests.  The only information XCB has about outstanding
> requests is that the connection's request sequence number is
> higher than the sequence number of the last processed reply.
> For now, I think you're gonna have to maintain your own
> queue of information on the requests you've sent out.  Once
> we get experience with your app, maybe we will want to build
> a generic library for this style of interaction with XCB.
> 
> Does this seem to everyone involved like a sane way to
> proceed?

i don't see how the XCBGenericResponse hooks up to any of the Cookies returned
by xcb calls. there's nothing in common there. from an api standpoint i
generally dont like digging into data structs - i like them opaque, but the
mechanism of using cookie->seqnum sounded better and comparing to the connection
seqnum. personally i would think providing accessor functions to provide for a
nice api would be better there. ie "has the seqnum of this cookie been recieved
yet" that would do just fine.

also i have to ask why allm the cookie data structs are different per request,
but they end up all being the same internally with the same single int value?
what was the reason for this? this makes doing the above kind of work harder -
either i have to assume this and cast them all to int's or special case every
single cookie reply type - and theres no "parent" type i can rely on to be
common. ?

> 	Bart
> 
> In message <20030426180447.60015617.raster@rasterman.com> you wrote:
> [...]
> > aaah i see - i'll need to check. good stuff - bytw where did you get the
> > xshm protocol specs?
> 
>   xc/doc/hardcopy/Xext/mit-shm.PS.gz

thats the same as the pdf's around - no protocol specs, just the shm library api
info :)

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
                                    raster@deephackmode.org
Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9698 8615