-*- mode: Text -*-
Flick --- Flexible IDL Compiler Kit
Eric Eide, James Simister, Tim Stack,
Kevin Frei, Eric Pabst, 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
August 1999
This is Flick version 2.0, 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, if needed (in the `support' directory), are
distributed under various licenses; see the file `COPYRIGHT' for details.
The text of the Flick 2.0 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. 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.
For an introduction to Flick's overall design and internals, please read our
PLDI '97 paper, ``Flick: A Flexible, Optimizing IDL Compiler,'' available from
the Flick Web pages at . The
`doc/guts' manual in this distribution is incomplete and out of date. It is
included only because it contains partially accurate details that might be of
interest to hackers and collaborators.
We welcome comments, technical discussion, and collaborators. If you start
using Flick, please let us know; send mail to
with the message body containing the line
subscribe flick-users
to get on the mailing list. Send bugs and fixes to .
CHANGES SINCE FLICK 1.1
Flick 2.0 is a major step forward from Flick 1.1 and incorporates many new
features and bug fixes. Most notably:
+ Flick now supports the CORBA C++ language binding in addition to all of the
(C language) bindings previously supported by Flick 1.1. Flick generates
optimized C++ stubs that work with TAO version 0.3.23, the real-time, open
source ORB from Washington University in St. Louis. You will need to
acquire a copy of TAO 0.3.23 in order to make use of Flick's C++ stubs.
For information about TAO, see .
+ Flick has new support for certain CORBA features such as sequence release
flags, `is_a' operations, and `any' types. (In this release, `any' support
is implemented only for C++ stubs running atop TAO.)
+ Generated stubs are now much more robust in the face of runtime errors
(e.g., out-of-memory conditions or malformed messages).
+ Flick can now generate specially ``decomposed'' C language stubs from CORBA
IDL. These non-standard stubs separate different aspects of RPC into
different functions, thus providing clients and servers with fine-grain
control over communication. This feature is experimental and our runtime
support for these stubs is incomplete. For more information about
decomposed stubs, please read our paper presented at LCR '98, available
from the Flick Web page .
+ Flick's internal representations have been expanded to support Flick's new
features; e.g., CAST now describes both C and C++, and PRES_C has features
for describing complex language mappings such as the CORBA C++ binding.
(This only affects users who write their own Flick compiler components.)
+ Lots and lots of miscellaneous bug fixes.
STATUS
Flick 2.0 is reasonably robust, but this is not to say that it is bug-free.
Projects already using Flick include:
+ QuOIN, the Quorum Distributed Object Integration Project, led by BBN. This
DARPA-funded project is combining technology from many researchers in order
to create a unified, flexible, and quality-of-service aware framework for
distributed object computing.
+ 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 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
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 with Flick's CORBA components (e.g., no
`wchar' or `wstring' types, missing support for `any's in the C language
IIOP runtime, 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.
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 100--200MB 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) greater optimization, (2)
quality-of-service and security, (3) user-directed presentation modification,
(4) support for very high speed network protocols, (5) support for target
languages other than C and C++, such as Java, 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/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.