%% -*- mode: LaTeX -*-
%%
%% Copyright (c) 1995, 1996, 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.
%%

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

%% This introduction is adapted from the introduction to the user's guide.

\section{What is Flick?}
\label{sec:Intro:What is Flick?}

Flick is a flexible and optimizing compiler for interface definition languages
(\IDL{}s).  The name ``Flick'' is an acronym for ``Flexible \IDL{} Compiler
Kit.''  Like a traditional \IDL{} compiler, Flick can read a high-level
specification describing an interface to a software component or module, and
from that, produce special functions called \emph{stubs} that implement the
interface in the C or C++ programming language.  The stubs implement remote
procedure call (\RPC{}) or remote method invocation (\RMI{}) semantics and
allow separate client and server processes to communicate through what appear
to be ordinary, local procedure calls or method invocations.

Unlike traditional \IDL{} compilers, however, Flick is implemented as a set of
programs, each handling a single phase of compilation.  These separate programs
allow Flick to support features beyond the capabilities of ordinary \IDL{}
compilers:

\begin{itemize}
  \item \emph{Multiple \IDL{}s.}
  %
  Most \RPC{} and distributed object systems, including \CORBA{} and \ONCRPC{}
  (Sun \RPC{}), specify \emph{an} \IDL{} and from then on refer to it as
  \emph{the} \IDL{}\@.  Flick, however, does not introduce a new \IDL{} but
  instead supports a number of existing ones side-by-side.  Any \IDL{}
  supported by Flick can be used to generate stubs for any environment (with
  some limitations).  Supporting multiple \IDL{}s allows for backward
  compatibility and migration of existing programs, and also allows developers
  to choose the best \IDL{} for the task at hand.

  \item \emph{Flexible language mappings (a.k.a.\ ``presentations'').}
  %
  Flick is designed to allow the appearance and behavior of generated stubs to
  be altered to suit the needs of the particular client or server in which
  those stubs are used, without altering the ``on-the-wire'' protocol between
  client and server.  In other words, Flick provides a framework for creating
  and modifying language mappings from \IDL{}s to target programming languages
  (currently, C and C++).

  A language mapping is implemented by what Flick calls a \emph{presentation
  generator}.  The current framework allows Flick users to tweak a language
  mapping through command line options to a presentation generator, e.g., to
  change the patterns used to build names, or to tell the presentation
  generator to create ``decomposed'' stubs instead of ordinary stubs (as
  described in Section~\ref{subsec:PG:Decomposed Stubs Presentation}).
  Large-scale modifications, however, currently require a Flick programmer to
  write C++ code to implement the modified language mapping (as a new
  presentation generator).  In the future, we hope to make it possible for
  ``ordinary users'' to make more and more complicated changes to language
  mappings, e.g., through some sort of special-purpose ``presentation
  definition language.''

  \item \emph{Sophisticated code generation and optimization.}
  %
  Flick was originally targeted toward communication in microkernel-based
  systems.  In that environment, Flick provides the user-level glue between the
  microkernel's primitive \IPC{} facilities and user-level application code.
  This target environment implies that Flick-generated stubs must be \emph{very
  fast}: good microkernels always have extremely fast and tightly optimized
  primitive \IPC{} paths, so inefficient stubs could easily raise the effective
  \IPC{} time by an order of magnitude.  Today, Flick produces optimized code
  for \emph{all} of its supported transport facilities including \TCP{}-based
  transports and lower-level, microkernel-based \IPC{}\@.

  \item \emph{Multiple back ends.}
  %
  Finally, while many \RPC{} and distributed object systems claim to support
  multiple transport protocols, the protocols they support are generally only
  slight variations of each other.  For example, \ONCRPC{} supports multiple
  transports in the sense that it can pass messages across either \TCP{} or
  \UDP{} links.  However, the basic data encoding scheme used (\XDR{}) is the
  same in each case, as are the stubs generated by the \IDL{} compiler.  The
  multiple protocol support is really just a stream-based abstraction layer in
  the \RPC{} runtime support library.  There is little hope, for example, that
  the \ONCRPC{} system could easily be made to support the \CORBA{} Internet
  Inter-\ORB{} Protocol (\IIOP{}) even though both are based on \TCP{}\@.

  Flick, on the other hand, aggressively supports multiple protocols by
  allowing different stub code generators (back ends) to be used
  interchangeably.  Each back end has complete control over the \RPC{}
  protocols that it implements: the back end determines not only the underlying
  transport protocol (e.g., \TCP{}, \UDP{}, Mach~3 messages, direct function
  call, etc.)\ but also the data encoding scheme used (e.g., Sun's \XDR{},
  \DCE{}'s \NDR{}, \CORBA{}'s \CDR{}, ``dumb'' architecture-specific encoding,
  etc.)\ and the high-level \RPC{} protocol layered above the low-level stream
  or message protocol (e.g., \ONCRPC{}, \CORBA{} \IIOP{}, Mach~3's \MIG{}
  protocol, etc.).  Flick contains several back ends supporting extremely
  diverse protocol combinations.
\end{itemize}

Flick is being developed as part of the Flux Operating Systems Project at the
University of Utah.  However, Flick is intended to be an open ``kit'' that
others will extend and adapt for their own projects.

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

%% End of file.

