CHAPTER 1 Introduction
Embedding is a key feature in modern user interface systems. Systems that support embedding include OLE, the Andrew Toolkit, and OpenDoc. To understand embedding, let's look at a prototypical embedding example. Consider a word processor program that embeds a spreadsheet table. Such a table could be embedded, for example, by selecting it from within a spreadsheet program and then drag-dropping it onto the word processor. Key to embedding is what is called in place editing. This means that the a user can edit the table without the need to explicitly start the spreadsheet program. When the user changes focus from the text to the table (by clicking on the table, for example) then the spreadsheet program implicitly kicks in and replaces the word processor's menus (toolbar, etc.) with its own. The user can now edit the table with all the features of the spreadsheet program.
Why graphical embedding? Suppose the user "zooms in" in order to make the word processor's text appear very large. The question is this: should the scale transformation applied to the word processor cause the spread sheet table to appear large as well? The answer, of course, is yes. In Fresco, since the embedded table is represented as a "viewer" glyph, and since any glyph can mix arbitrarily with graphically transforming glyphs, the scale transformation applied to the word processor does indeed cause the table to zoom. Now whereas this may seem the obvious thing to do, few if any systems actually do this. In fact most systems require the shape of an embedded object to be an opaque, non-transformed, screen-aligned rectangle. Fresco, on the other hand, allows embedded viewers to be arbitrarily shaped (even with holes) and arbitrarily transformed. The shape of a viewer, for example, can be the result of a 3D perspective projection.
Let's move from graphical embedding to distribution. To provide for object distribution, Fresco is "OMG CORBA compliant". OMG stands for Object Management Group. This is a consortium of roughly 380 member companies headquartered out of Framingham, Massachusetts. The OMG began in 1991 to define CORBA--the Common Object Request Broker Architecture. CORBA has been standardized by the OMG, and CORBA2 is now in the works.
Within the word CORBA you'll see the letters ORB, which means Object Request Broker. An ORB is the mechanism that allows objects to communicate (make requests) across address spaces and across the network. An ORB provides services such as the network transmission of messages and automatic tracking of objects.
In order to define a "CORBA compliant" object, a designer uses IDL--CORBA's Interface Definition Language. Once defined, IDL objects can be implemented in a variety of languages. The OMG has standardized (or is currently working on) bindings from IDL to C, C++, SmallTalk, Objective C--and other language bindings are on the way. The X11R6 implementation of Fresco uses C++, and an ADA94 version of Fresco is also in the works.
IDL looks a lot like C++. One thing to note is that IDL is for defining interface only: there are no constructs for defining storage (storage is an implementation detail) and there are no programming constructs such as loops, conditionals, or expressions. Figure 1-4 shows a partial definition of Fresco's Glyph interface and its corresponding C++ counterpart generated by Fresco's IDL to C++ translator called ix (for interface translator). The generated C++ gives you a good idea of the mapping between IDL and C++. (The formal mapping is still being standardized by OMG so there exists some possibility of future changes.)
As seen in figure 1-4, interfaces in IDL map to abstract classes in C++. These contain no data and cannot be instantiated (note protected constructor) and, as such, by themselves provide no implementation. Class Glyph derives from FrescoObject which contains operations for runtime type identification and memory management, including reference counting.
Operations in IDL, such as draw(), map to virtual functions in C++. Attributes, such as glyph_style, map to get/set function pairs. Parameters in IDL come in three flavors: in, out, and inout. Objects are passed as object references. For example, the "in GlyphTraversal" passed to the IDL draw() operation is an object reference. Object references map to pointers in C++.
In CORBA, object references are "transparent" in terms of address space and network. This means that a call to a remote object will look syntactically equivalent to a call to a local object. For example, the following C++ code segment takes a Fresco glyph object, g, and calls the draw() operation on it.
g->draw(t);
Since g is an object reference, it is transparent in terms of address space and network. Thus, by looking at this line of code, we cannot tell if the glyph lives in this address space or in another address space or across the network.
This transparency is implemented using the C++ virtual function mechanism. For example, suppose the glyph has its implementation object in the same address space where the draw() operation was called. In this case, g points directly to the implementation object. Its vtbl, of course, contains pointers to implementation functions, so the overhead of calling draw() is simply that of a C++ virtual function call--there is no additional runtime overhead.
If, on the other hand, the glyph's implementation object is in a different address space, then g's vtbl will contain pointers to functions that know only how to prepare the arguments and then make an RPC. Obviously, calls made on remote objects involve significantly greater overhead than those to locally implemented objects. Fortunately, at least in the case of Fresco, the vast majority of communication occurs between objects in the same address space.
Generated with CERN WebMaker