Received: by ATHENA-PO-2.MIT.EDU (5.45/4.7) id AA16384; Tue, 12 Sep 89 12:59:32 EDT
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15224; Tue, 12 Sep 89 13:00:11 EDT
Received: from ATHENA (ATHENA.MIT.EDU) by expo.lcs.mit.edu; Tue, 12 Sep 89 12:58:36 EDT
From: dcc@ATHENA.MIT.EDU
Received: by ATHENA.MIT.EDU (5.45/4.7) id AA15197; Tue, 12 Sep 89 12:59:28 EDT
Received: by THANATOS.MIT.EDU (5.61/4.7) id AA00554; Tue, 12 Sep 89 12:58:15 -0400
Message-Id: <8909121658.AA00554@THANATOS.MIT.EDU>
To: com-orl!thg@uunet.uu.net
Cc: xvideo@expo.lcs.mit.edu
Subject: re: Basic Concerns about VEX
Date: Tue, 12 Sep 89 12:58:11 EDT

>
>I am NOT surprised at the lack of response to your comments on the VEX
>protocol. At the end of last year I started getting involved with VEX and
>raised the same sort of issues, or at least issues at the same sort of level.
>The problem is that, even then, the fundamental ideas of what should be in the
>extension and what shouldn't had been reasonably well decided. The current
>discussion has moved on from "Well, do we need all this translucency stuff?"
>via "How exactly do we want to express translucency?" to "Which sentence in
>the protocol specification should we change?"
>

Thanks Tim, this input is helpful; it exposes an obstacle I've
encountered.  So far the underlying message I've gotten from
respondents is that VEX is basically complete, except, perhaps, for
changes that are cosmetic in nature.  Another message I've heard,
however, is that there hasn't been broad participation in the basic
design, Todd gave me a list of 3-4 names (yours included), and you say
that you tried to "raise the same sort of issues" and that even then
the basic design was decided.  Now, I don't think that this is any big
flaw, quite the contrary, that's the way the X Window System started,
and one reason I believe it was able to make great progress, but
before it became standard, it had much broader participation and
changed greatly between revisions.

>The standard response to any suggested change to VEX is "What does your change
>allow me to achieve that the current specification doesn't?" This clearly
>rules-out any change which removes functionality from specification, which is
>what you are suggesting. Sorry, but that's just the way it is!

Well, assuming that the process becomes open to discussing
the basic design and conceptual model, there are many goals
besides increasing functionality, that I would advocate:

  o  logical completeness

  o  device independence and abstraction

  o  clearity

  o  simplicity

  o  internal consistency

  o  external consistency (i.e., with X and other extensions)

  o  usefulness


