%% -*- mode: LaTeX -*-
%%
%% Copyright (c) 1997, 1999 The University of Utah and
%% the Computer Systems Laboratory at the University of Utah (CSL).
%%
%% This file is part of Flick, the Flexible IDL Compiler Kit.
%%
%% Flick is free software; you can redistribute it and/or modify
%% it under the terms of the GNU General Public License as published by
%% the Free Software Foundation; either version 2 of the License, or
%% (at your option) any later version.
%%
%% Flick is distributed in the hope that it will be useful,
%% but WITHOUT ANY WARRANTY; without even the implied warranty of
%% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
%% GNU General Public License for more details.
%%
%% You should have received a copy of the GNU General Public License
%% along with Flick; see the file COPYING.  If not, write to
%% the Free Software Foundation, 59 Temple Place #330, Boston, MA 02111, USA.
%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\com{
\title{Logical Runtime and Header Separation for Flick}
\author{Kevin Frei}
\date{January 7, 1997}

\begin{document}
\maketitle

\section{The Problem}
}%\com

\section{Logical Runtime and Header Separation for Flick}
\label{sec:Runtime:Logical Runtime and Header Separation for Flick}

Flick's support of multiple presentations over multiple ``transports'' brings
with it many real problems:

\begin{itemize}
  \item What interface to the ``runtime'' does the user expect?
  \item What interface does Flick need to the link layer?
  \item At what level is the presentation independent of the link layer?
  \item Where should we separate the link layer from the message format?
\end{itemize}

This section is an attempt to deal with those problems in a manner that will
allow Flick to grow to support additional link layers, message formats, and
presentation without serious changes to the runtime interface.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Definitions}
\label{subsec:Runtime:Definitions}

Here are the terms I'm going to be using, and what I mean by them:

\begin{description}
  \item[Presentation] The way an \IDL{} maps to a given language.  This
  includes everything the user of the stubs must know in order to use them
  properly.

  \item[Message Format] The way the bits look in the buffer being transmitted.
  \XDR{} and \CDR{} are message formats.

  \item[Link Layer] The way a buffer is transmitted between client and server;
  the interface to the network.
\end{description}

Trouble occurs when you really try and divide these three things as completely
independent entities.  Link Layer influences message format and presentation.
Presentation influences Link Layer (and to some small degree, message format),
etc.  That is the real problem.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Presentation Issues}
\label{subsec:Runtime:Presentation Issues}

Presentation primarily consists of the basic language mapping.  Exception/error
mapping is a presentation issue.  All errors that occur in stubs generated by
Flick should call presentation dependent code that deals with the error
accordingly.  This code should be found in the header
\texttt{<flick/pres/\emph{presentation}.h>}.  This header DOES concern the
user, because it should contain all information about how to extract
information about exceptions and errors.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Link Layer Issues}
\label{subsec:Runtime:Link Layer Issues}

The link layer is primarily used by Flick internally --- send request to
server, get request from client, send reply to client, get request from server.
The link layer also specifies what the \emph{object reference} data structure
should be.  For example, Sun's \RPC{} link layer (\TCP{}/\UDP{}) specifies that
the object reference needs to contain an IP address, and a port number to be
created.  Once the object reference is created, it only really needs a socket
number, though.

This is not as separable as it may initially seem, though.  Object reference
construction and destruction is the job of the user, generally (except for
object references as parameters), so this needs to be exposed to the user.  The
code for the normal ``Create a client object reference'' or ``Destroy a Client
object reference'' function should be kept separate from the code that Flick
uses internally.  So, as a user/presentation issue, these functions
\emph{should} be found in the header
\texttt{<flick/pres/\emph{presentation}.h>}.  They are not, at this time.
Continue reading\ldots{}

We should have presentation level object references that translate to link
layer object references.  This can be accomplished fairly efficiently by simply
tagging the presentation object reference with an intermediate object reference
representation, then a conversion to the link layer object reference would be
made when the connection is actually created.  The user would simply link their
files to the appropriate link layer library, which would implement
\cfunction{flick_create_obj_ref}.  This would prevent the N by M pairing of
presentations and link layers.  When the information supplied is simply
insufficient to create a valid object reference on the selected link layer, an
alternative call could be made, using specific information.  An example of this
problem might be attempting to use the Sun \RPC{} presentation with the Mach~3
link layer.  An IP address and a server identifier are insufficient to actually
find the correct Mach port.  In this case, the user could manually call
\cfunction{flick_create_obj_ref} with the Mach port they're using.

This approach should be sufficient for the problem, but would require more time
to implement.  As an initial pass, there will be a header, found in the
\filename{flick/pres} directory that is named
\texttt{\emph{pres}\_on\_\emph{link\_layer}}.  The link layer object reference
information, as well as the information for using the link layer from within
Flick stubs and skeletons will be located in
\texttt{<flick/runtime/\emph{link\_layer}.h>}.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Message Format Issues}
\label{subsec:Runtime:Message Formal Issues}

The message format is almost completely separable from the link layer.  The
\texttt{flick/format/\emph{encoding}.h} header should implement the macros for
globbing, chunking, and bit layout.  While there are plenty of arguments
against this division (we really do need a USC-like IR for this thing\ldots{})
this is the way it is going to be for now.  The header may contain some
assumptions about the buffer layout, at least for now.  This buffer information
should eventually be encoded and dealt with appropriately, but for the initial
cut, this overlap is acceptable.

\com{
\end{document}
}%\com

%% End of file.

