Sun/Mac Interoperation

[Mark S. Miller <mark>]

Date: Sun, 20 Aug 89 18:13:36 PDT
   From: roger (Roger Gregory)

   ...

   2) The x address probably will have to tell us what external thing it belongs 
   to. (right mark?) In the FE for acad, it won't be strictly true that the FE
   doesn't understand the address, it can tell that it belongs to acad. ...

There are actually two issues being intertwined here.  One is whether
the document contents are external to Xanadu or not (whether they live
in ESpace), and the other is whether a given front-end application
knows how to handle a given document type.  CadDoc exercises both of
these issues, so let's introduce two new examples in order to get a
full matrix.  

			        This FE		        Other FE
			+-----------------------+--------------------
Storage in Xanadu BE:	|   Local Textual Doc	|    Samson Diagram
			|			|
			+-----------------------+--------------------
Storage in ESpace:	|   Document in Lexis	|    CadDoc
			|			|


(gosh, don't you love character graphics!)

In the above, I'm assuming that the "current FE" in question knows how
to dial the phone and get text from an external service (like Lexis),
that it doesn't itself know how to display a Samson Diagram, but it
knows how to find an application that can.

The storage in Xanadu vs ESpace issue is resolved by whether the
backend will report actual data in response to a "dataMap" retrieve,
or whether it gives EAddresses.  Note that a user cannot directly
distinguish the case where the backend didn't give the data because it
didn't contain it, or because this user wasn't permitted to see it.

An EAddress consists of two parts: a containerID (which is a StampID),
and a position within the container.  The containerID will generally
be annotated with a ROD (Remote Object Descriptor), which is to be
interpreted somehow by the front-end as a description of where this
container actually resides.  In other words, the be is delegating to
the fe this final step of finding the data.  In CadDoc as I've
currently built the protocol, the ROD consists of a PackageOfBits
which I expect to contain the hostname&filename of the relevant
AutoCad file.  Consider this a short-term special case, in that the
ROD doesn't identify itself as one which describes location via
filename string.  It just does it.

As to the other distinction, this is distinguised by work-type (which
hasn't yet been put into the Docs&Links layer).  When the fe retrieves
a document, it should inspect its work type and see if it is one it
knows how to deal with (knowledge both of a Waldo to wrap it with, and
of a way to present it).  If it doesn't, presumably there could be
some resolution from info attached to the work type to an application,
much like the resolution from a containerID to an external data
source.

Doing this well and in general is probably a hard problem.  It is also
much like problems that the Sun "Link Sever" people have been dealng
with.  In the case of CadDoc for AutoFact we will of course just
special case this.

Once both fe applications are up and talking to each other, the issue
of their IPC protocol is also similar to issues that the Sun folk have
been dealing with.  I hadn't realized until this discussion how their
work relates to ours.