[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: Inclusion Lists for Hypercardus Clonus
- To: <ravi>
- Subject: Re: Inclusion Lists for Hypercardus Clonus
- From: Michael McClary <michael>
- Date: Wed, 14 Feb 90 12:04:06 PST
- Cc: <marcs>, <roger>, <xtech>
> From ravi Wed Feb 14 11:07:10 1990
> From: michael (Michael McClary) [desiderata for frontend behavior] 
> - Providing a user-hook for conformance-checking and attempting to
> view it as various known types. (i.e., a temporary "cast")
> Automatically shows as the most complex known type.
Yes, but if there is a more-complex type endorsement that is clearly a
"type", the frontend should let you know that the display may be somewhat
Also, until you tell the frontend that this user-flavored PackOBits
is a bitmapped image ala-Sun, it has no way to know that it can display
it as a bitmapped image ala-somebody-else that it DOES know about,
rather than a hex dump.
> - Providing a user-hook for automatically confomance-checking-and-
> displaying future occurrences of new-type-"foofoo" data as
> existing-type-"foo" data. ("remember cast")
> Might be a simple extension. Once it's all in place I'll take a look.
This is a frontend behavior, which consists of maintaining a local
(or backend-stored) table of "display foofoo as foo", where "foofoo"
is typically a type that didn't exist when the frontend shipped.
Remember, the "foo" will typically be a user-defined higher-level
frontend-running waldo that wraps the Xanadu-supplied low-level
backend-supported waldo. Xanadu is out of the loop, except to
provide a good initial example to get the developers herded in
the right direction.
> Seems to me it might be wise for the backend to provide a hook for
> "claims to conform to standard 'foo'" which is publicly endorsable
> for every "conforms to standard 'foo'" endorsement. A frontend
> developer could chose to display (after checking) foreign data that
> claims to conform to his standards. (He might also have his product
> automatically endorse data it found to be conforming, to accellerate
> display in other sessions.)
> Since any Joe can use the endorsement, I'm not sure it's worthwhile
> doing as a system function. The conversion is going to have to be done
> from the raw system type anyway, so the developer might just as well
> provide the conversion for anything that the user at the time wants to
> look at as a foo. If a developer finds it useful to provide a public
> might-be-foo endorsement, they can.
No, MUST be done as a system function (or a system-imposed pattern-of-use),
because there must be a cannonical way to recognize a "claims-to-be"
endorsement when it is encountered.