The Flick compiler cannot stand on its own, it needs a runtime to implement some basic functionality for the stubs. This functionality includes things like transmitting messages, receiving messages, and managing objects. In several cases, Flick's back ends use Flick's minimal runtime systems -- they are designed to get the job done, but usually do not implement the full range of features that a commercial runtime might. However, a few of Flick's back ends are geared toward externally developed runtime systems, such as TAO.
The set of runtimes located in the runtime/libraries/link are minimal in functionality. They provide the absolute bare-bones infrastructure needed to get an object/server and send messages back and forth. The various back ends provided with Flick are keyed to use these libraries; however, one can always adapt the back ends to one's needs.
Flick's runtime libraries are contained under the runtime/libraries directory of the Flick distribution:
Khazana and Fluke are separate projects that maintain their own runtimes, so they are included directly in Flick. See http://www.cs.utah.edu/flux/ for information about Fluke and http://www.cs.utah.edu/flux/ for information about Khazana.
The IIOPXX back end targets the TAO real-time orb from Washington University in St. Louis. This orb implements the majority of the corba spec; however, the spec doesn't include requirements for transmitting a raw message to another object and other low level functionality. Fortunately, TAO exports enough of this functionality for Flick to do its job. Unfortunately, this is not part of the public interface and like the internal implementation details of any system, it is is likely to change over time. As such, Flick must be adapted to these changes as they occur to take advantage of newer versions of TAO. As of this writing, the IIOPXX back end has been designed for and tested with with TAO version 1.0.
Flick's support of multiple presentations over multiple "transports" brings with it many real problems:
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.
Here are the terms I'm going to be using, and what I mean by them:
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.
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 <flick/pres/presentation .h>. This header DOES concern the user, because it should contain all information about how to extract information about exceptions and errors.
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 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 should be found in the header <flick/pres/presentation .h>. They are not, at this time. Continue reading. . .
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 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 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 flick/pres directory that is named pres _on_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 <flick/runtime/link_layer .h>.
The message format is almost completely separable from the link layer. The flick/format/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. . . ) 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.