Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!bloom-beacon!ZERMATT.LCS.MIT.EDU!RWS
From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Detecting/Compressing Multiple Exposure Events - how ?
Message-ID: <19880902015804.9.RWS@KILLINGTON.LCS.MIT.EDU>
Date: 2 Sep 88 01:58:00 GMT
References: <130@tityus.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 25


    Date: 1 Sep 88 21:36:01 GMT
    From: vsi1!daver!athsys!jim@AMES.ARC.NASA.GOV  (Jim Becker)

	    I believe that this would only cause minor mods in the five
    XCheck*() routines, and the additional logic is trivial. I understand
    that you guys have a lot to do to get R3 frozen, but this may be a
    worthwhile change. If there are no other changes in these routines since
    R2, I can make the changes and post them to xbugs. Ten minutes of fixes!

People need to understand that the number of minutes it takes to fix the
code is somewhat irrelevant.  What matters is that there is a standard
definition of the Xlib interface, and it doesn't willy nilly get
changed.  There is a process that has to get followed.  And, at this
particular point, stability of interfaces is rather important, to
vendors and to developers.  There are many products in-progress out
there, being built to comply with current interfaces.  Those products
are on varying schedules, none under the control of MIT.  Many are close
to being "out", and a number of companies already have products out.
You can't just change an interface and expect that all vendors will be
able to instantly make the change.  For some, it make a year to fold it
into their release cycle.  Those are realities that we have to live
with.

This isn't to say we'll ignore your suggestion, just that expecting it
as part of Xlib in R3 is not realistic.