-*- mode: Text -*-

		      Flick --- Flexible IDL Compiler Kit

	      Eric Eide, Kevin Frei, Eric Pabst, James Simister,
		    Bryan Ford, Jay Lepreau, Gary Lindstrom
			       flick@cs.utah.edu

		     The Flux Project, University of Utah
		     http://www.cs.utah.edu/projects/flux/
				+1-801-585-3271

				   May 1998


This is Flick version 1.1, an interface definition language (IDL) compiler
(``stub generator'') that generates optimized code and supports a variety of
IDLs and message transport mechanisms.  The Flick compiler is distributed under
the GNU General Public License; see the file named `COPYING' for details.  The
Flick runtime headers and libraries are distributed under a separate license
(BSD-style without the advertising clause); see the file `runtime/COPYING' for
details.  Additional support files (in the `support' directory) are distributed
under various licenses; see the files themselves for details.

The text of the Flick 1.1 announcement is in the file `doc/announce.text'; see
that file for additional details such as the list of tested platforms.  For
help building Flick, see the `INSTALL' file.  For an introduction to Flick's
overall design and internals, read `doc/flick-pldi97.ps', our paper that was
presented at PLDI '97.  The `doc/usersguide/user.ps' file is the Flick user's
manual, complete with code examples.  The `doc/BUGS' file describes known
defects and as-yet-unimplemented features.

The `doc/flick-guts' manual, describing Flick's internals, is incomplete and
out of date.  However, it still contains partially accurate details that might
be of interest to hackers and collaborators.  Similarly, `doc/headers.ps' is
out of date but possibly interesting to hackers.

We welcome comments, technical discussion, and collaborators.  If you start
using Flick, please let us know; send mail to <flick-users-request@cs.utah.edu>
with the message body containing the line

	subscribe flick-users

to get on the mailing list.  Send bugs and fixes to <flick-bugs@cs.utah.edu>.


			    CHANGES SINCE FLICK 1.0

Flick 1.1 fixes many bugs from the Flick 1.0 release and also includes several
new features.  Most notably:

  + Flick now supports CORBA and ONC RPC over Trapeze, the fast Myrinet-based
    network technology from Duke University.  For more information about
    Trapeze, see <http://www.cs.duke.edu/ari/manic/tpz_www/trapeze_root.html>.

  + The new `support' directory contains sources that one needs in order to use
    Flick under Windows/GNU-Win32: header files, `libnsl', and a portmapper.

  + Flick can now produce CORBA stubs that use Mach ports --- CORBA on Mach!
    (Preliminary; some message encoding inefficiencies need to be worked out.)

  + Flick's MIG components have been *greatly* improved.  Flick now supports
    almost all of the MIG IDL, and Flick-generated stubs are as fast as those
    generated by MIG itself.

  + Flick's CORBA runtime has been greatly improved: bugs fixed and performance
    increased.


				    STATUS

Flick 1.1 is reasonably robust, but this is not to say that it is bug-free.
Projects already using Flick include:

  + The Fluke Operating System.  Flick is the IDL compiler for Fluke, a new
    operating system being developed by the Flux Project at the University of
    Utah.  See <http://www.cs.utah.edu/projects/flux/> for information about
    Fluke (and Flick, too).

  + Porcupine.  Porcupine is a scalable SMTP/IMAP server designed for
    high-volume mail exchange --- up to one billion messages per day.  See
    <http://grad-pc1.cs.washington.edu/porcupine/> for more information.

  + The CS 453 `TICS' Group.  A group of students in our Department's senior
    software lab used Flick to implement RPC for distributed robot control
    systems.  Flick itself is run on a Unix machine, and the generated IIOP
    stubs are compiled for both Unix and Windows NT, enabling cross-platform
    communication and development.

A list of known bugs and caveats can be found in `doc/BUGS'.  In brief:

  + There are some minor shortcomings to the CORBA presentation generator (no
    `any' types, etc.).

  + There are still some dependencies between the front ends and the
    presentation generators.  This means that one cannot ``mix and match'' IDLs
    and presentation generators.  For example, you can't start with a Sun RPC
    (a.k.a. ONC RPC) IDL file and get CORBA-like stubs.

  + In principle one can ``mix and match'' different presentations and back
    ends, e.g., Sun IDL and presentation could talk IIOP to a similarly
    specified system.  However, the only unusual combinations that have been
    tested recently are CORBA-on-Mach, CORBA-on-Trapeze, and ONC-on-Trapeze.
    Other unusual combinations are unlikely to work.

  + We have recently been doing lots of work on the various runtimes (for IIOP,
    ONC RPC, Mach3MIG, Trapeze, and Fluke), so watch for bugs.


		       TESTING FLICK / EXAMPLE PROGRAMS

Flick comes with a set of test inputs and example programs in the `test'
subdirectory of the distribution.  See the `test/README' file for instructions.
Note that, *except* for the `test/examples/phone' application, the example
programs in `test/examples' are not up to date and may not compile.

You will need 35--70MB of free disk space in order to run the Flick tests.

Refer to the user's manual and the `test/examples/phone' sample application to
learn how to use Flick's IIOP and ONC RPC runtime libraries in your own
programs.


				     PLANS

We currently plan to work in six main areas: (1) support for target languages
other than C, such as C++ and Java, (2) greater optimization, (3) user-directed
presentation modification, (4) security and QoS, (5) support for very high
speed network protocols, and (6) support for the (OSKit) COM presentation.

As a start on these goals, we plan to reevaluate the current design of Flick
and to reimplement the parts that have ``worn out.''  We have many ideas for
improvements that are difficult to implement within the current framework; for
example, the back ends need a better model for marshaling and unmarshaling data
in order to support such things as scatter-gather processing.  We need new
intermediate representations for low-level data formats and for high-level
target languages other than C.  We plan to incorporate USC-style (O'Malley et
al., SIGCOMM '94) representations for all types, allowing Flick to have a more
flexible and powerful copy optimizer.  We need to generalize our models for
runtime support and security.  Finally, the time has come for a good dose of
software engineering.

In all of these efforts, we welcome collaborators and discussions with others
building IDL compilers or runtimes, to see where overlapping goals can lead to
common code.

## End of file.

