The Micro Hyper-Tool Protocol
-----------------------------

General Discussion:

There are several possible protocols for hypertools ranging from execution
of arbitrary scripts in a remote application to procedure call interfaces
common to all tools.  Currently there are no widely accepted protocols for
communication between hypertools.  Since Tk/Tcl allow arbitrary scripts to
be sent to any Tk based application, little control is possible and the need
for protocols is great.  Executing arbitrary scripts in remote applications
may be effective if the sending application has 'knowledge' of the workings
and state of the receiving application, but in general this knowledge results 
in a high level of coupling.  Providing a consistent procedure call interface
to an application's state, data, and functionality provides a lower level
of coupling and thus the ability to replace inter-changeable applications.  

The Micro Hyper-Tool Approach:

The MHT approach is simple: The application is a library.  Well designed
and implemented libraries have well defined interfaces which allow access to 
internal states, data, and functionality.  A MHT will provide external 
interfaces to its functionality.  The main draw back in this protocol is that 
each MHT is expected to "play nice" with the other applications, respect the 
protocol, and follow its conventions.  

The main advantages of providing a procedure call interface are reduced 
coupling and greater control of the commands executed by exported procedures. 
Arbitrary scripts can still be sent to applications using exported procedures, 
but the need for them is greatly reduced.

The Protocol:

Each application should provide a set of procedures which allow other 
applications to access and/or change the state or data of the application or
to make use of it's functionality.  The provided procedure names should follow 
the convention of beginning with 'export_' followed by a descriptive word or 
two.  In practice several words will most likely be required, each should be 
separated by an underscore (_).  This convention provides the benefits of 
having consistently named procedures which are obviously for external control.

Owning and Grabbing:

MHT applications should support three states, free, owned, and grabbed.  Free
applications are not dedicated to any one application, and so can be used
independently or by another application. Owned applications are dedicated to 
one application, usually the one which started them.  Usually owned 
applications exit after they have completed their required tasks. Grabbed 
applications are started as free applications but are temporarily owned 
(grabbed) by an application but which requests their services.  Each 
application should provide an interface named export_grab which temporarily 
takes ownership of a free application.

tess, tkcd, and tkcf:

The tess application provides a simple means for determining the contents
of and extracting files from a compressed (or gziped) tar archive.  tess uses
the MHT conventions to make use of tkcd and tkcf.  tkcd is a tool used for 
changing the working directory of a running Tk based application.  tkcd is a 
tool which can be used for changing the current file in use by a a running Tk 
based application.  Each of the above applications provide a procedure named 
export_cd which is currently used by tkcd.  This means that one instance of
tkcd can be used to control another instance of tkcd.

The tkcd tool can be "owned" by another application either permanantly or
or temporarily.  If tkcd is started by another application, for example tess,
it is considered to be owned.  If it is started on its own (from the command
line) it is considered free.  A free MHT can be grabbed and thus temporarily
owned by another MHT.  Usually the grabbed MHT will free itself and return to
a free state after it has completed it's task.  This allows several MHT to
share resources.
