[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DESCRIBE-INTERACTIVE (Version 4)
- To: Dan L. Pierson <pierson%mist@Multimax.encore.com>
- Subject: Issue: DESCRIBE-INTERACTIVE (Version 4)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 16 Nov 88 13:33 EST
- Cc: email@example.com
- In-reply-to: <8811152214.AA07001@mist.UUCP>
Date: Tue, 15 Nov 88 17:14:16 EST
From: Dan L. Pierson <pierson@mist>
Moon opposes NO because "it creates extra work for implementors and
users of at least one implementation, for no compelling reason."
I still take that position.
Moon suggested as a compromise only allowing DESCRIBE to require
user input from "interactive streams". Several other members of the
committee like this in principle but question whether it's feasible
since we have neither defined "interactive streams" nor provided any
portable way to tell if a stream is interactive.
You yourself proposed INTERACTIVE-STREAM-P in issue STREAM-CAPABILITIES
on July 5. I'm not sure why this issue has gotten nowhere, but I suspect
it is because two essentially unrelated proposals got mixed together; one
is INTERACTIVE-STREAM-P, the other is the attempt to standardize a way to
tell whether two streams connect to the same ultimate source or sink of
data. I don't think it's at all problematical to define INTERACTIVE-STREAM-P
in a practically precise enough way.
The STREAM-ACCESS proposal, which is released but apparently not voted on,
could have incorporated INTERACTIVE-STREAM-P, but apparently it didn't.