[comp.windows.x] Strict/Lenient

battle@alphard.cs.utk.edu (David Battle) (12/20/89)

In article <8912182057.AA05745@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes:
>
>    calls to XGrabPointer() with an event mask of -1, which caused a
>    problem with the Sony R3 server (invalid argument).
>
>That actually makes it a post-R3 server, then. :-)  This is a typical
>bug in R3 clients that will cause them to lose against strict R4 servers.

    Hmmm.  The more I think about it, the more I think that there should be
two kinds of servers; strict ones for developers to use which would not
allow them to get away with anything, and lenient ones for users to use
so that things don't break.

    Strict servers would not only refuse to put up with invalid arguments
and such, but would also actually (and deliberately) do random things at
points where behavior is unspecified.  They would represent the least
common denominator of what all servers are expected to do (at least all
servers which the developer expects his code to run on).

    Lenient servers would do only enough checking to prevent real trouble.
They would support backward compatible features to the largest extent
possible without conflicting with revised features.  They would support
existing practice whether or not that practice was compliant with written
standards.

    In this way many problems could be avoided.  The strict servers would
make excellent test beds for applications which needed to be portable.  The
lenient servers would allow users to get on with their work without spending
too much time worrying about incompatibilities.  Their existence would not
only give users lots of extra time to phase out older applications while
taking advantage of new server features, but would also alleviate the
temptation to build non-standard backward compatible features into all
servers, thus allowing developers to continue to rely on those features.

    Window managers could be built along these lines also.  In fact, this
same principle could be applied to compilers and operating systems.

					-David L. Battle
					 battle@battle.esd.ornl.gov