[Xcb] [RFC libxcb 0/5] Fix GE events from the ground up, leading to a full 64bit sequence API

[Daniel Martin]

On Tue, Jun 04, 2013 at 04:17:25PM -0700, Josh Triplett wrote:
> On Wed, Jun 05, 2013 at 12:52:01AM +0200, Daniel Martin wrote:
> > we need to fix GE events to be able to support extensions using such
> > events properly. Atm. xcb_ge_event_t has the full_sequence field at the
> > 32byte boundary, where it's not supposed to be, because GE events can be
> > larger then 32byte.
> [...]
> > A summary of the visible (API) changes:
> > - Removed the full_sequence from
> >     xcb_generic_event_t,
> >     xcb_ge_event_t and
> >     xcb_generic_error_t.
> > - Added a function to be able to get the sequence, which has a parameter
> >   to adjust its behavior (wait, poll or just watch the queue for
> >   events):
> >     xcb_rcv_event()
> > On top of that I additionally changed the remaining "sequences". That
> > means:
> > - Made cookies have uint64_t sequences
> > - Changed all sequence parameters to uint64_t. Most of those functions
> >   aren't "that" public. They're wrapped in the specific request/reply
> >   functions. And the change usually was: changing an 'in' parameter from
> >   unsigned int to uint64_t, which shouldn't be a big deal if you would
> >   still pass an unsigned int.
> > With that, libxcb uses uint64_t for sequences from the beginning to the
> > end. (No widen() is necessary anymore.)
> 
> I'm all for this change; it makes much more sense for xcb to return the
> 64-bit sequence numbers out-of-band rather than shoehorning it into what
> should be wire-format structures.

Thanks. So, I was not going in the wrong direction.

> However, I'd propose doing this in two steps.  First, add a new set of
> functions and structures that follow the pattern described above,
> leaving the existing ones in place, and deprecate the old ones.

I tried to avoid to add new structures as that may lead to confusion.
(At least on my side, while finding a proper name. ;) ) But, deprecating
the old ones and offering a a new set sounds much more easy to adopt in
other projects.

> Second,
> remove those functions and bump the SONAME.  The first of those two
> changes should be uncontroversial; we can then argue over when (or if)
> we should do the latter without delaying the former.

I didn't thought about removing the old functions. With my changes the
SONAME would need to be bumped too, but for libxcb users it would just
mean to recompile them - if they don't use the full_sequence field.

I'll change my patches to follow this 2 step approach (skipping the
removal for the moment).


Thanks for your comments,
    Daniel