by Kirk Searls
Bento: [Japanese] 1. A box lunch or picnic lunch. 2. A box or basket with multiple compartments, containing a collection of disparate elements arranged in an esthetically pleasing manner.
What does a picnic basket have to do with developing OpenDoc part handlers? A bento is a container that has many compartments where you can place different things. Each compartment has its own size and shape, and its contents are distinct from any other compartment. This is the type of container needed for OpenDoc's powerful, complex document architecture. The Bento Specification, created by Apple Computer, Inc., defines two things: a format for containers of compound content and an API. OpenDoc systems use Bento technology as a common format for the storage and interchange of compound document information because it provides:
- Easy and efficient access to different pieces of data
- Support for compound content by allowing many types of data for an object and allowing many objects in a file
- Support for interoperability between applications (for example, adding a new and previously unknown type of data to an object does not break existing applications)
- Support for interoperability between platforms by isolating platform-specific code in a few easily modified functions
- 1 How Does the Bento Technology Achieve All This?
- 2 The Bento Data Model Simplifies Data Storage
- 3 Containers
- 4 Objects
- 5 Properties, Types, and Values
- 6 Bento Handlers Provide Portability and Extensibility
- 7 Session Handlers
- 8 Container Handlers
- 9 Value Handlers
- 10 Standardization Provides Interoperability
- 11 How Does the OpenDoc System use Bento Technology?
- 12 Summary
- 13 Reference:
- 14 About the Author - Kirk Searls
How Does the Bento Technology Achieve All This?
Bento technology provides a data model which defines data easily and clearly. The Bento API provides the ability to add new data types to existing objects without disturbing existing data (or access to it). Bento technology uses dynamically linked functions (handlers) for all the low-level, platform-dependent functions such as reads, writes, and seeks.
This article describes Bento's data model, how Bento technology uses handlers, and how an OpenDoc system uses Bento technology.
The Bento Data Model Simplifies Data Storage
One way to support saving data for multiple applications in one file is to let each application create and manipulate separate streams within the file. Bento technology goes beyond this and defines the following entities that it uses to define and access data:
- Properties, Types, and Values
Objects consist of a set of properties and exist within the container. A property defines the information to be saved, but not the type or format of the data In fact, each property can have many different types of data associated with it; however, it can have only one value for each data type associated with it. Each value consists of a variable-length sequence of bytes. Each object must have at least one property that has at least one value. The following diagram shows the relationships between these entities:
Containers are the picnic basket that holds all the compartments (the bento), and can be any type of storage that the operating system provides. A container determines the type of storage that is used for all its objects, properties, types, and values.
An obvious container is a file; however, you can use other types of storage such as memory, the clipboard, or even Bento values. And, if you use a Bento value for a container, that container can be embedded in other Bento containers.
Each Bento object has a persistent ID that is unique within its container. Objects don't really exist independent of their properties; that is, an object contains no information beyond what is stored in its properties.
Properties, Types, and Values
The easiest way to understand these entities is to compare them to data definitions in C. A property is like a C variable name, a type is like a C data type, and a Bento value is similar to the storage that is associated with a C variable. Consider the following C statement:
long EmployeeID; // Storage contains a number such as 0001
In the Bento representation of this statement, the property is EmployeeID, the type is long, and the value is the four bytes in memory that is used for the variable. Since Bento objects contain properties they are similar to structures in C. However, the following differences exist:
- In Bento technology, properties can be added at any time; elements of a a structure are statically defined in C.
- In Bento technology, property names are globally unique; element names are only unique within a structure in C.
- In Bento technology, a property can have many types with one value for each type; a variable has only one type and one value in C.
- In Bento technology, a type is just a description of the format of a value. The size of a value in a Bento system is when the value is created and grows as data is written to it. The maximum size of a value in a Bento system is 264 bytes. A variable's type determines the size of its value in C.
Bento Handlers Provide Portability and Extensibility
Handlers are dynamically linked functions that users of the Bento API provide. In most cases, Bento uses handlers to access operating system-dependent functions.
A session is associated with the currently running process. Operations, such as memory management and error reporting, are global to the session as a whole. Session handlers provide these operations to provide portability across platforms.
Containers provide access to operating system storage. The handlers that are associated with a container implement the storage access and determine the type of storage used. For example, a seek handler function for a file container finds a particular of fset in a file; the same function for a memory container accesses an address at a particular offset in memory. Container handlers provide the same stream I/O interface to the Bento library (no matter what type of storage is used).
By providing all the I/O for the Bento library, container handlers provide portability and extensibility. A specific type of container, such as a file container, can be implemented on different platforms by providing the appropriate handlers for each platform. In addition, new types of containers can be created by providing handlers that access different types of storage.
Value handlers are provided for extensibility. These handlers can add data transformations such as compression or byte-swapping on data before the data is seen by an application. These handlers are also used to implement indirect values, where the Bento value is actually a pointer to another piece of data, such as a file or a database.
Standardization Provides Interoperability
Bento technology lets data from many applications coexist in the same container. That is, they can read and write their own data without stepping on another application's data. To achieve interoperability between applications at the data level, applications must read and interpret each other's data.
The following diagram shows a layered view of the content of a Bento container.
Figure 1. Bento Container
The top two levels are provided by the Bento library. The next two levels require a process to register and standardize Bento types and properties. Public types and properties consist of basic types such as strings, floating point numbers, and dates. Private types and properties are directed at standards that are required in specific areas such as multimedia. Local types and properties are required when an application has data that has not been defined in the upper levels. You achieve the greatest in teroperability by defining data in terms of the types and properties in the upper levels of the pyramid.
How Does the OpenDoc System use Bento Technology?
What does this all mean to someone who wants to develop an OpenDoc part editor? Does an OpenDoc developer have to know the Bento API? Does he have to create handlers for Bento? How does a OpenDoc developer take advantage of the benefits provided by Bento?
Bento technology forms the basis of the storage system that will be supplied as the reference implementation of OpenDoc systems on each platform (such as, OS/2). Therefore, a guaranteed common format will exist for all platforms, which will assist interplatform interoperability. OpenDoc systems will achieve further interoperability through the efforts to register and standardize Bento types and parts.
The interface to Bento technology is hidden inside of the OpenDoc system's storage system classes, so the administrative work is done by the OpenDoc class library. OpenDoc systems implement both file-based and memory-based containers, which includes the handlers for both types of storage.
OpenDoc technology, through its storage system, creates Bento objects, properties, and so forth to define the persistent data for documents, drafts, and other persistent objects. It also creates Bento objects for OpenDoc parts. You'll notice that OpenDoc system uses properties, types, and values are, in fact, the same properties, types, and values that are defined by the Bento technology. OpenDoc developers will create the appropriate properties, types, and values necessary to represent the contents of a part.
This description of the Bento technology and how the OpenDoc system uses it was intended to provide an overview of the concepts and benefits of Bento. The specifics are available in the Bento Specification, which is available on your accompanying CD-ROM. Also on the CD-ROM is a copy of the Bento APIs.
- Harris, Jed and Ira Ruben. Apple Computer, Inc. Bento Specification, Revision 1.0d5. July 15, 1993.
About the Author - Kirk Searls
Kirk Searls is leading the development team for OpenDoc on OS/2. He has been working with C++ and object-oriented programming for the past 6 years. Previously, Kirk worked on the object-oriented GUI for the Distributed Application Environment (DAE).
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation