On Mon, Jun 17, 2019 at 7:33 PM Michael McLaughlin <mikebmcl_at_[hidden]>
wrote:

> We, the authors, felt that trying to design everything at once was too
> large of a task.
>

Perfectly reasonable position.


> We decided that we would choose to pursue one half of 2D Graphics I/O and
> that input meant and means very little unless there is some definition of
> what the user's input is in relation to. Just as if a user simply typed
> into a console without any initial prompt or resulting feedback.
>

Sure, although I wouldn't diminish the individual importance of input as
much as you seem to be implying.

It is, of course, possible to design an input API first, but until that API
> relates to some output that the user experiences, it has no tangible
> meaning.
>

Right. But..


> It is simply keystrokes, mouse or touch movements, or clicks or taps.
> Meaning could be assigned to them in some way by users (viz. the theremin),
> but the input would have no ties to anything other than a blank screen.
>

You seem to be asserting that a screen is the only "meaningful" output with
regards to feedback of input. The multitude of force feedback devices,
light "bulb" indicators, heat surfaces, audio generators, scented vapor
devices, nerve stimulation, etc would seem to indicate otherwise.

As such, we decided to focus on output first.
>

Understood. But can you please provide the actual justification in the
paper of why you made that choice instead of the demonstrably inaccurate
one of API interdependence mentioned in 0.1.1p5? As it will avoid future
arguments like this one :-)


> If an input API had been designed around R6, it would've required serious
> modification in order to fit in the the current output API.
>

This statement worries me to no end. There are plenty of industry examples
of input APIs that don't depend on the design of the output API. And I
would consider such an interlocked design choice counter to well
established separation of concerns design principles.


> That said, feedback from the committee has resulted in many changes to the
> API, most recently from the San Diego 2018 meeting, which led to the
> creation of the command lists feature. (No review of P0267 took place an
> Kona 2019).
>

I must have been really tired that day as I don't remember command lists
coming up :-\

All of that said, I do have one item of reference material at hand that
> supports our decision. The organization of *Computer Graphics -
> Principles and Practice*, 2d ed., Foley, van Dam, et al., Copyright 1996
> Addison-Wesley Publishing Company, Inc., Reading, MA. (Apologies if my
> citation format is incorrect). In it, Foley, van Dam, and the other
> co-authors address 2D graphics output first and only after that is finished
> (along with a brief foray into 3D graphics), i.e. the first seven chapters,
> do they begin to address input (chapter 8...).
>

Hm, I lent my copy of that one to my work library so I can't look it up
right now... But sequencing of learning material doesn't correlate with API
design dependence.

But it really was just a choice, one made long before any of us happened to
> have a copy of Foley and van Dam in reaching distance. I hope that I
> respectfully stated the reasons we chose output first. If my response does
> not seem respectful I sincerely apologize and ask that you forgive me. I've
> been awake for well over a day just now (the mailing deadline was almost 12
> hours ago and adrenaline has been flowing through me ever since!).
>

It was perfectly respectful and well explained. Just doesn't address my
concern. Which is essentially that what you just explained as the rational
is not what's in the paper. And no worries.. many of us have been in that
same adrenaline infused position :-)

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net