The rationale for G2 (and G2++)

G2 was designed to address one of the most fundamental issues in interprocess communication: What form should the records take? One strategy (which you may have actually used) is to send raw structures. The following example illustrates this strategy. It involves two processes which exchange raw Request and Reply structures through a pipe:

   transaction.h
           struct Request{
               char name[20];
               char address[40];
               struct{
                   short area_code;
                   long number;
               }phone;
               long dollar_amt;
           };

           struct Reply{
               char code;
               long acct_no;
           };

   client.c
           #include "transaction.h"
           main(){
               Request r;
               Reply p;
   communication set-up
               write(wfd,&r,sizeof(Request));
               read(rfd,&p,sizeof(Reply));
           }

   server.c
           #include "transaction.h"
           main(){
               Request r;
               Reply p;

   communication set-up
               read(rfd,&r,sizeof(Request));
               ...
               write(wfd,&p,sizeof(Reply));
           }

Unfortunately, this solution is highly environment-dependent: it only works as long as both processes run on the same machine, or two machines with identical numeric representation, wordsize, byte ordering, alignment restrictions, and so-on. Since the trend in modern message-based systems is increasingly toward distributed solutions involving networks and heterogeneous machine architectures, raw structures do not represent viable long-term strategy. ``Guidelines for Using G2'' lists several examples of the kinds of differences (in addition to hardware) that tend to develop among independent computing environments, including programming languages and (perhaps most importantly) the record definitions themselves.

Different schemes have been proposed as an alternative to raw structures. Some of these abandon structures altogether and provide client programs with a purely functional interface to data items. FML is one such scheme. The disadvantage of these schemes is that functions must be called to store and retrieve each data item. Their advantage is that reading and writing are usually fast. Other schemes continue the practice of representing records as C structures inside client programs, but provide runtime support for mapping the structures to and from some standard external representation (for example, ASCII name-value pairs). These schemes have the advantage that all data manipulation is performed directly in the host language, with all the efficiency of the underlying data types. Their overhead occurs in reading and writing records. G2 is one such scheme.