A remote presentation-based user interface

[rwk@crl.dec.com (Robert W. Kerns)]

    Date: Thu, 8 Aug 1991 12:05-0500
    From: lgm@iexist.att.com

    The presentation-based user interface style directly supported by
    Dynamic Windows and CLIM generally seems to assume that an object and
    its presentation reside on the same processor, since the presentation
    maintains a reference to the object to which it refers.  I need,
    however, to provide a manipulable interface to *remote* objects (i.e.,
    objects on other processors).  None of the user interface software can
    run on the remote processor; so I cannot, for example, simply run an X
    screen off that processor.

    Let's say I represent each remote object by its name (of type SYMBOL).
    Is it safe, for all DW/CLIM purposes, to directly present an object name
    (a SYMBOL) with the presentation type of the remote object's class
    (which is a CLOS user-defined class)?  Or must I define an entire shadow
    hierarchy of "ambassador" presentation types (which eventually expand
    into type SYMBOL), and present each object name with its corresponding
    "ambassador" presentation type?  Anyone have a better idea?

There is no reason that your presentation types must somehow
turn into SYMBOL.  In fact, unless you want operations designed
to work on things you think of as symbols to work on them
(unlikely), you should *NOT* make your presentation types turn
into SYMBOL.

You don't indicate whether the CLOS classes will be present on
your local machine.  This matters to what course I would suggest.
As a result, I'll be vague and general, and answer you with a bit
of philosophy and wandering hypotheticals.  Sorry.

I don't know what CLIM 2.0 will do, and I don't recall what CLIM
1.0 does now, but I do know that, unlike DW, in CLIM 0.9, defining
a class does not automatically make that available as a presentation
type, with the same inheritance.  Despite this, I would regard it
as a Bad Idea to define a presentation type named FOO, represented
by a symbol, on the same machine which also has a class named FOO.

However, if there really is a full separation of roles between the
two pieces of software, without there being similar local objects,
I think it would be a Fine Idea for the local presentation types
to be named in parallel, with parallel structure, but I would make
the structure more sparse.  Much of a class hierarchy has to do
with implementation choices, not semantics; generally presentation
types should be defined for objects which share a given semantics.
For example, for the classes for CARTESIAN-POINT and POLAR-POINT,
I would build the classes to both inherit from POINT, and I would
define a presentation type for POINT, not for CARTESIAN-POINT.
Let generic functions handle distinguishing differing implementations.

Classes like POINT above are often termed "protocol classes",
and make fine places to attach presentation types, because they
correspond with a given set of functionality.

On the other hand, if you DO have the same set of classes on both
ends, I would first ask "Why"?  If you are doing it in order to
get the inheritance for the presentation-type system (in DW, or
maybe in CLIM 1.0), I would say "forget it"; it is leading to
the "Bad Idea" I referred to above.

On the other hand, if you're really using the same CLOS hierarchy
on both machines, I would identify the relevant protocol classes,
give them (PRESENTATION-TYPE :ALLOCATION :CLASS 
			     :INITFORM your-type-here
			     :READER FROB-PRESENTATION-TYPE)
slots, and establish a uniform naming convention between class
name and presentation type, to help maintain your sanity while
developing.

Presentation types are more abstract than classes.  So I would
*NOT* define a fully parallel presentation-type hierarchy.
It is logically unnecessary, unweildy, and hard to maintain.

Remember, presentation-types are more abstract than classes.
You can then use FROB-PRESENTATION-TYPE on your object to
find what the appropriate presentation type is.  Use your
presentation type for both the symbols and the class instances.
Remember, presentation-types are more abstract than classes.

Further, remember that presentation types are more abstract than
classes.  A presentation type may convey additional information
about how an object is USED.  Thus, your presentation type can
refer to your symbol in its role as a standin for an instance
on another machine, without reference to its SYMBOL-ness.  But
further, it may sometimes refer to an even MORE SPECIFIC abstract
role; it might be an INPUT, or a RESULT.  This may or may not
relate to the presentation-type hierarchy you're defining to
go with the CLOS hierarchy.  Because presentation types are more
abstract than classes.

Because in the final analysis, presentation types are more
abstract than classes.  They deal with ROLE; classes at their
most abstract deal with PROTOCOL, which links ROLE to IMPLEMENTATION,
which is handled by the less abstract classes.

But this wouldn't be symetric if I didn't remind you finally:
Presentation types are more abstract than classes.

----------------

Your question answered, let me raise another for you to think about.
Why are you representing your object with symbols?  Why not use class
instances?  Then you can use generic functions to manipulate them,
can make some decisions locally based on class without having to talk
to the other machine, etc.  You can even run the same code on both
machines transparently; if run on the same machine with the instances,
it it will do the stuff locally; if run on the machine with the remote
server, it will go over the net.

Just keep clear the distinction between protocol classes and implementation,
and this becomes pretty simple to manage.  One protocol (i.e. set of
generic functions and their contracts).  Two different implementations.
And a set of generics for creation of your objects, which choose the
class based on whether you're local or remote.  (These could be generics
on other objects, or even on a keyword gotten from a global variable)

Just remember that on many implementations, MAKE-INSTANCE runs more
efficiently if the first argument is a constant, so a function to
compute what class to use is NOT recommended in performance-critical
sections.

Another way of looking at this, is that you're using CLOS to build
a richer model of what you have on the other end of the network
connection.  This richer model allows you to tailer your code more
closely to what is going on, to the point where you could even run
the code with the instances on the same machine with the UI.  This
may help you debug your UI!