Gamelon® 3.0: An Overview Of New Functionality
Gamelon is a programmer's library that provides object-oriented persistent data management facilities through n-dimensional iterator cursors that navigate logically through stored objects for search and update. The library is available on many computer platforms and with many computer language and environment interfaces. It is characterized by low memory usage, small footprint and type-safe storage.
Gamelon was designed for use with software agents on platforms with limited resources, but its performance and storage capabilities are also suitable for much larger systems.
Improvements in the Gamelon persistent storage library API fall principally into three functional categories: indexing, data distribution and encryption. Briefly stated, keyvalue indexing has been added; the library supports the management of objects exchanged among network nodes; and objects may be separately encrypted at any level of object nesting. These topics are now treated in more detail, and some miscellaneous changes are noted at the end.
Indexing.
Gamelon uses a two-tier concept of indexing: primary indexes associate OIDs (object identifiers) with physical file placement, and secondary indexes associate keyvalues with OIDs. If an OID is already known, a cursor can be moved to the object through use of a primary index; if a keyvalue is to be used, a search of a secondary index holding such keys will produce all of the OIDs associated with the keyvalue; then each OID can be used with a primary index to obtain object placement.
The actual offset of an object in a Gamelon file is not disclosed through the API. The reason for this is that the placement of objects is not stable: they are moved around by garbage collection services that periodically condense and optimize the file layout. It is entirely sufficient to address an object logically by placing a cursor on it, because the cursor is stable and the apparent relative position of objects addressed through a cursor is always correct. The garbage collector automatically updates all primary indexes, so that placement information is kept up to date.
Primary indexes can be attached to any cursor, with the result that file alterations (additions and deletions) of OID-bearing objects made through that cursor are automatically updated in every attached index. Similarly, primary indexes can be associated with a cursor, with the result that those indexes will be employed automatically when a call is made to move the cursor to the object that bears a particular OID. It is also possible to make direct updates to primary indexes and to have all changes to OID-bearing objects within a range (made through any cursor) to be automatically updated to one or more primary indexes.
Secondary indexes are not attached or associated with cursors for update and navigation purposes (although a future version of Gamelon may do this), but -- like primary indexes -- they are inherently persistent. Secondary indexes are used as service objects that maintain and find keyvalue/OID associations.
Because the association of OID and physical location is unique to a given file, a primary index can support just one file, and duplicate entries are automatically excluded. On the other hand, there is no limit to the number of primary indexes that can support the same file, and the index need not reside in the file that it supports.
No such limitations apply to a secondary index, which produces the OID that matches a keyvalue: it does not matter where the object bearing that OID resides, or even whether it still exists; and duplicate keyvalue entries can occur naturally. Because there may be good reason to keep keyvalue entries that resolve to actual objects only when a particular primary index is used to find the objects, this deliberate disconnect can be productive for data organization purposes.
Secondary indexing is new to the Gamelon API. It is a full-featured facility, which includes predefined keyvalue collation functions but also permits the programmer to create a new collation function appropriate to sort an arbitrary key -- a binary key that is meaningful in ways unknown to the designers of Gamelon.
Both primary and secondary indexes are maintained through cursors, which take on special index-related functionality for that purpose.
Data Exchange.
In order for persistent object storage to operate, it is necessary for objects to have unique OIDs. This creates an architectural problem for systems that are not strictly hierarchical or not tightly-coupled, because it becomes difficult to assure the uniqueness of OIDs that are not centrally assigned and managed. Because Gamelon was designed for use in a loosely-coupled, peer node environment, it was designed to address this problem, and version 3.0 includes necessary API services.
In the Gamelon system, every item of data is an object and every container is an object: this permits logical navigation among containers and data items, and it permits annotation of any object and cross-linkage of any object with any other object.
It would be a waste of space and computational overhead to cause every object (such as an integer) to bear an OID, because in most systems only higher-level objects, such as records, need to be found by OID,annotated or linked to one another. Therefore, the Gamelon system provides for optional application of a unique OID to any object.
Even optional use of OIDs must involve storage and memory space allocation, and therefore the size of an OID is to be considered. The current implementation of Gamelon uses a 4-byte OID which is unique at the computer node on which the library is employed, but the library was written to allow easy substitution of any other OID-generating function, such as one that will generate a large random number OID.
The 4-byte OID permits the use of four Billion unique OIDs at a given node, which is quite adequate for nearly all purposes. This does create a need, however, for a means of avoiding OID conflicts when an object is moved from one node to another -- such as by exchange of files across the Internet. Version 3.0 of Gamelon handles this problem automatically by using node identifiers embedded in exchange files and by applying new OIDs to received objects (while keeping a log of the node+OID origin of each newly-received object); it even takes care of automatic updating of the OID values of received indexes, so that the integrity of imported indexes is maintained.
Alternate means of providing universally-unique OIDs in a distributed system can be made available in custom adaptations of the library.
Encryption.
Version 3.0 now provides functions for the encryption and decryption of any object in a Gamelon file, including the encryption of objects that enclose other encrypted objects. A secret key method conformant to U.S. export controls is used.
Customized versions of the library can be adapted to other encryption methods, including public key/ private key. Inquire of Menai if you have such a need.
Miscellaneous.
In Version 3.0, there have been improvements in execution speed. The previously-available Beta versions of ActiveX and Java interfaces have now been finalized, and small accomodations have been made to adapt the Gamelon API to those interfaces so that the interfaces will work naturally in the application builder environments for which they were designed.
Home | Product | Consulting | Programming | Reviews | Company | Site Map | Guest Book
Menai Corporation, 1010 El Camino Real, Suite 300, Menlo Park, California 94025-4335
800-GAMELON (800-426-3566) (US only), 650-853-6450 (voice), 650-853-6453 (fax)
Questions about our products and services: info@menai.com.
Comments about this web site: webmaster@menai.com.
Copyright © 1996-98 Menai Corporation. All Rights Reserved. Menai, Gamelon and gamelon(stylized) are worldwide trademarks of Menai Corporation, registered in the United States of America, and the .[g] logo is a worldwide trademark of Menai Corporation. All other trademarks are owned by their respective owners.