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

[Bart Massey]

In message <20030427104627.098f7c2f.raster@rasterman.com> you wrote:
> 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 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.

The answer to your first question is that if the
GenericResponse is a GenericRep, one of its fields is a
sequence number to match against cookies'.

We can do the latter thing.  As I suggested in a previous
message, we can provide
   int XCBForcingWouldBlock(XCBGenericCookie c)
which I think answers the question you posed.

Does this answer your question?

> also i have to ask why all 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. ?

The whole idea is to enforce static type checking, making it
difficult to pass e.g. a pixmap cookie to a routine that
wants a property cookie.  Casting the cookie to a
GenericCookie and taking its sequence number field is
harmless: the cookies are all guaranteed to have this.

XCB definitely encourages a different programming model
(actually several different models) than e uses.  I don't
think it's hard to make XCB do pretty much what e needs,
though.

	Bart