[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: Inclusion Lists for Hypercardus Clonus



> 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
bogus.

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.
Trivial.

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.

	michael