This document outlines the implementation language and associated toolkits
chosen for the implementation of the Dward Caiman GUI. The shortlisted
choices were C and Java. Both were considered based on the requirements
listed below.

Requirements/Criteria:
----------------------
 1. Have the necessary toolkits and libraries to provide a native 
    look and feel (JDS nimbus theme, look and feel)
    for the installer GUI and closely adhere to Dwarf GUI spec.
 2. Provide a clean and efficient interface with the Caiman Orchestrator
    via the APIs provided by the Orchestrator.
 3. Can be bundled into a solaris miniroot image and have reasonable
    runtime memory footprint.
 4. Provide a enough out of the box utilitylibraries, types and classes
    so that excessive "rolling our own" isn't necessary.
 5. Speed of implementation
 6. Minimum learning curve for JDS GUI engineers.


Implementation language: C + the GTK+ toolkit and GNOME desktop libraries.

Evaluation against requirements/criteria:
-----------------------------------------------------------------------
1. The native solaris desktop (JDS) look and feel is GTK+ based 
   and it's implementation and APIs are all written in C. This
   ensures the best possible look and feel conformance in the
   installer GUI. It also makes other GNOME desktop libraries available
   for future use (eg. html rendering & network transparent file
   access) as GUI requirements evolve.
2. Assuming the Orchestrator will be written in C and provide a 
   C based API for the GUI, C is the most obvious and direct 
   language to use to interface with the Caiman Orchestrator.
3. Not dependent on a memory heavy runtime VM environment being
   loaded into a memory based filesystem. Additionally, the necessary
   GUI toolkit library (GTK+) is already required by the gnome window
   manager (metacity) so there is little or no additional cost on top
   of metacity's existing runime requirements.
4. C's standard libraries are very basic and primitive compared to 
   richer development platforms such as Java. That said, the GNOME project
   has built up quite a rich set of libraries which we can make use of.
   The Glib and Gobject base libraries which form the foundations of the
   GNOME desktop stack offer a number of useful enchancements to the
   standard C libraries:
   -  main event loops, threads, thread pools, asynchronous queues,
      dynamic module loading, IO channels for supporting files, pipes
      & sockets, error logging etc.
   - Numerous utilities including string utility functions, date and time
     functions, timers, process spawning, file utilities, XML subset parsers.
   - Data types for linked lists, queues, hash tables, strings arrays, etc.
   - A fully featured object class implementation (GObject)
   - A signalling mechanism allowing signal registration, connection & emission
   On top of this the GNOME desktop platform libraries provide a rich pool
   of utilities and pre built components to draw from tailored towards GUI
   application development.
5 & 6.
   The GNOME/JDS desktop is almost entirely written in C and this,
   therefore, is the language the JDS GUI engineers are most familiar
   with writing GUI interfaces in.


Implementation language: Java 1.6 platform.

Evaluation against requirements/criteria:
---------------------------------------------
1. As of JDK 1.6, swing does quite a reasonable job of creating a
   native looking application on JDS because it uses the GTK theme
   engine to draw it's widgets. It still doesn't have rich platform
   integration with the JDS desktop beyond the basic widget toolkit
   however. There are java-gnome bindings to integrate better with
   the gnome desktop but they are currently buggy, memory hungry,
   imcomplete and currently unmaintained in the community. The 
   community's focus has shifted to a complete rearchitecture and
   reimplementation of the bindings. 

2. Java can interface native C libraries using JNI, however this
   adds an extra layer of complexity and implementation cost.

3. Requires the Java virtual machine to be loaded into memory,
   consuming scarce resources in the constrained installation
   environment.

4. The Java platform is offers a far richer development platform
   than the standard C libraries even when glib and gobject are
   factored in. The downside is that it's integration with the
   GNOME desktop is quite limited. 

5 & 6.
   The JDS GUI engineers would need some additional time to come
   up to speed with Java based GUI implementation. Combining this
   with the extra work involved in writing a JNI layer interface
   with the C based orchestrator APIs would be too time consuming
   in the Dwarf Caiman time frame.


Having considered both, I feel that either language/platform choice
would be technically suitable. The Java platform doesn't offer any
compelling advantages over the combination of C and GTK+ despite
it's superior feature set. It also has some significant disadvantages
as outline above given the  time constraints of Dwarf Caiman's schedule.
For this reason I  feel that C, Glib, GTK+ and the native stack of GNOME
platform libraries make a  better choice for Dwarf Caiman.