Integration of data between typed objects by mutual, direct invocation between object managers corresponding to object types

What is claimed as new and desired to be secured by Letters Patent of the United States is:

1. A data processing system in which data is represented as typed objects, the system comprising:

(A) a plurality of object managers for performing operations with respect to objects, each object manager including

(a) means for performing at least one operation with respect to at least one corresponding type of object,

the means for performing at least one operation being responsive to a request to perform an operation of the at least one operation with respect to an identified object of the corresponding type for performing the requested operation with respect to the identified object,

(b) means for identifying in a first, corresponding type of object a reference to a second object,

(c) means responsive to the identification of a reference to a second object for generating a request for an operation with respect to the second object,

each request including an identification of the second object and an operation to be performed with respect to the second object,

(B) means for receiving from a requesting object manager an identification of a second object and an identification of an operation to be performed with respect to the second object,

(C) means for using the received object and operation identifications to identify an object manager that includes means for performing the identified operation on objects of the type of the identified second object, and

(D) means for invoking the identified object manager, and

(E) means for communicating to the identified object manager a request to perform the identified operation on the identified second object,

wherein an object manager can both request invocation of other object managers and can itself be invoked by other object managers.

2. The data processing system of claim 1 wherein the plurality of object managers includes object managers with means for performing each of a set of standard operations for each type of object.

3. The data processing system of claim 1 wherein there is defined for each type of object a default operation and wherein the plurality of object managers includes for each type of object at least one object manager with means for performing the corresponding default operation.

4. The data processing system of claim 1 wherein

(i) the means for receiving, means for identifying, and means for invoking and communicating comprises a manager process,

(ii) the receiving by the means for receiving includes the receipt of the manager process of an interprocess communication from the requesting object manager, and

(iii) the invoking by the means for invoking and communicating results in the manager process spawning an object manager process.

5. The data processing system of claim 1 wherein the means for using the received object and operation identifications comprises means for accessing a data base that associates objects with object types, which access is used in identifying an object manager.

6. The data processing system of claim 1 wherein the means for using the received object and operation identifications comprises means for accessing a data base that associates object types with object managers, which access is used in identifying an object manager.

7. The data processing system of claim 1 wherein the object identification provided by the requesting object manager comprises a link identifier.

8. In an object based data processing system having a plurality of object managers for performing operations with respect to typed objects, each object manager including means for performing at least one operation with respect to at least one corresponding type of object, the means for performing at least one operation being responsive to a request to perform an operation of the at least one operation with respect to an identified object of the corresponding type for performing the requested operation with respect to the identified object, each object manager including a means for identifying in a first, corresponding type of object a reference to a second object and means responsive to the identification of a reference to a second object for generating a request for an operation with respect to the second object, each request including an identification of the second object and an operation to be performed with respect to the second object, an application manager comprising:

(A) means for receiving from a requesting object manager an identification of a second object and an identification of an operation to be performed with respect to the second object,

(B) means for using the received object and operation identification to identify an object manager that includes means for performing the identified operation on objects of the type of the identified second object, and

(C) means for invoking the identified object manager, and

(D) means for communicating to the identified object manager a request to perform the identified operation on the identified second object,

wherein an object manager can through operation of the application manager both request invocation of other object managers and itself be invoked by other object managers.

9. A data processing system in which data is represented as typed objects, the system comprising:

(A) a plurality of object managers, each object manager including means for performing at least one operation with respect to at least one type of object,

(B) a system data base that

(a) associates objects with object types,

(b) associates link identifiers wit specific objects, and

(c) associates object types with object managers, and

(C) a management means, including

(a) a means for receiving from a requesting object manager a link identifier and an identification of an operation,

(b) a means for accessing the system data base to identify the object to which the link identifier refers,

(c) a means for accessing the system data base to determine the type of the identified object,

(d) a means for accessing the system data base to identify an object manager that includes means for performing the identified operation on objects of the type of the identified object, and

(e) a means for invoking the identified object manager, and

(f) a means for communicating to the identified object manager a request to perform the identified operation on the identified object.

10. A data processing system for manipulating typed objects having links to other objects, the system comprising:

(A) a plurality of object managers for performing operations with respect to objects, each object manager including

(a) a means for performing at least one operation with respect to at least one corresponding type of object,

the means for performing at least one operation being responsive to a request to perform an operation of the at least one operation with respect to an identified object of the corresponding type for performing the requested operation with respect to the identified object,

(b) means for identifying in a first, corresponding type of object a link to a second object,

(c) means responsive to the identification of a link to a second object for generating a request for an operation with respect to the second object,

each request including an identification of the link and an operation to be performed with respect to the second object,

(B) storage means for storing information identifying links between objects,

(C) access means for accessing the stored link information, the access means being available to provide link information to all of the plurality of object managers, and

(D) management means, including

(a) a means for receiving from a requesting object manager an identification of a link and identification of an operations,

(b) a means for using the received link and operation identifications to identify an object manager that includes means for performing the identified operation on objects of the type indicated by the identified link,

(c) a means for invoking the identified object manager, and

(d) a means for communicating to the identified object manager a request to perform the identified operation on the identified second object,

wherein an object manager can both request invocation of other object managers and can itself be invoked by other object managers.

11. The data processing system of claim 10 wherein the plurality of object managers includes object managers with means for performing each of a set of standard operations for each type of object.

12. The data processing system of claim 10 wherein there is defined for each type of object a default operation and wherein the plurality of object managers includes for each type of object at least one object manager with means for performing the corresponding default operation.

Description Submit all comments and votes

CROSS REFERENCE TO RELATED APPLICATIONS

The present patent application is related to U.S. patent application Ser. No. 07/088,176 to Marc San Soucie, et al., titled CUSTOMIZATION BY AUTOMATED RESOURCE SUBSTITUTION, filed the same day as the present application, now abandoned.

FIELD OF THE INVENTION

The present invention relates to an object based data processing system and, in particular, to apparatus and methods for managing and integrating objects and programs for operating on objects.

BACKGROUND OF THE INVENTION

There are a number of major, general problem areas which recur in data processing systems and these problem areas are growing increasingly demanding in contemporary systems as the range of types of data and information processing applications and numbers and types of users grow. These areas include, in particular, the integration of applications and data in a uniform system and environment, the ability to add new applications and data types to an existing system in a manner to integrate the new applications and data types with existing applications and data types; the ability to update applications and, in particular, the ability to translate programs and data from one language to another as business interests and data applications become international in scope; the ability of different users to share data, and in particular data in a timely form so that each user has the most recent version of a particular body of data; and the ability to transfer or exchange data from one form or data structure to another.

A user may want to include a graph in a document. One existing way to provide the ability for the user to edit the graph from within the context of the document is to augment a document editor with graph editing capabilities. This approach has the disadvantage that in order to integrate a further new type of data (e.g., a voice annotation) into documents, it is necessary to again modify the document editor. In fact, each editor must be separately extended to handle each ne type of data.

While certain systems of the prior art have attempted to solve these problems, for example, by constructing object based systems wherein all data type reside in standardized data structures referred to as "objects", the systems of the prior art have generally failed to adequately solve these problems. In particular, the systems of the prior art have generally fallen into one of two classes. In the first and older class of system,, there has been little constraint upon data types and applications programs with the result that, while it is easy to add new applications and data types, it is difficult to provide an integrated system and user environment and very difficult to communicate data between users and data types. In the second and more recent class of system, such a the object based systems, there has been an attempt to provide a defined system environment. This approach provides an integrated system and user environment which facilitates the ability to communicate between users and data types. A recurring problem with this class of system, however, is that the system definition itself, and the operating system type programs necessary to manage defined and object based systems inhibits the ability to add new applications and data types if they do not fit within the applications and data types initially envisioned and defined.

SUMMARY OF THE INVENTION

The present invention provides for a highly integrate, yet extensible system by means of typed objects, object managers, and a generalized invocation mechanism that invokes an appropriate object manager to perform an operation on an object.

The system of the present invention does not utilize a central, operating system type object management system but provides a group of object management data structures and a plurality of "packs" of generic routines for performing operating system type tasks and many generalized applications program type tasks. The routine "packs" include a pack of generic object management routines, which are accessible and usable by all object managers, for operating upon the object management data structures, so that the object managers perform the object management functions. By this approach, new object types and new object managers, or applications programs, may be easily added to an existing system by simply installing an object manager and, using that object manager, generating the appropriate entries in the object management data structures.

Among the object management related data structures are an object catalog, used in the management of individual objects and links between objects, an object manager table used to relate objects and operations to be performed on objects to corresponding object managers, and an object prototype table used in the creation of objects. The object catalog includes an object table of all objects residing in the system. The object catalog also includes a link table, which has a record for each link to or from any object in the object table.

The object manager table provides for a plurality of object managers to operate with any given object type, including a primary object manager for each object type. The particular object manager invoked to operate upon a particular object may depend upon the type of operation to be performed an certain object managers may operate with more than one type of object. The association between object type, operation to be performed, and corresponding object manager is performed through the object manager table. That is, when a user selects to perform an operation upon a given object, the object management routines read the corresponding entry for that object type and operation from the object manager table to determine the corresponding object manager to be invoked.

The object prototype table contains information used in the creation of new objects. The object prototype table provides a means for accessing stored prototype copies of each type of object installed in the system. New objects of any given type may be created at will by making copies of the prototype copy of the object, the copy of the prototype object then becoming a new object which may be modified or operated upon at will by the user. A profile editor may be used to create a corresponding new profile for the new object and to modify the copy of the basic profile as necessary to reflect the modified characteristics of the object.

The system of the present invention also provides a means for linking or connecting data structures, such as objects, or portions of data structures. Linking also allows the dynamic copying of data or information from one data structure to another so that the destination data structure may be provided with the most recent version of the linked data residing in the source data structure.

A link may be regarded as a means by which one object, referred to as a "child" object, is "connected" to another object, referred to as the "parent" object. In addition to linking a child object to a parent object, a link may also be used to link a portion of a child object's data into a parent object. This linking of data from a child object to a parent object is distinct from the copying of data from one object to another in that the data which is linked remains a part of the child object rather than becoming an integral part of the parent object. Linked data may be edited only within the child object and only by an object manager designated for the child object type.

Data may be linked dynamically or statically. In the case of dynamic linking, the current version of the data is read from the child object and provided to the parent object each time the link is "updated". As will be described, a dynamic link may be updated, for example, each time the parent object is operated upon, that is, opened, displayed, edited or printed. Updating of a link may also be initiated at regular intervals, or keyed to operations upon the child object so that an update occurs whenever the child is modified or operated upon in some manner.

The system of the present invention provides an improved system for the exchange of data between data structures of different types. In a first aspect, the data exchange mechanism provides for a plurality of data exchange formats wherein each object manager for a given data structure may use one or more different exchange formats, depending upon the type of data structure with which the data is being exchanged. In the present implementation, the system provides for three classes of exchange formats. The first class includes generic formats used for data exchanges between structures of different types and different internal formats. The second class includes category specific formats used for data exchanges between data structures of the same type but different internal data formats, and the third class includes private formats for data exchanges between data structures of the same type and same internal format.

In a second aspect, the data exchange mechanism of the present invention provides a matchmaker mechanism whereby the object managers of two data structures may communicate regarding available exchange formats and which arbitrates a choice of a format for a data exchange.

An object of the present invention is to provide an open-ended framework for the integration of different applications programs. In this context "open ended" means that new applications should be integrated with existing applications without requiring modification of the existing applications.

A further object is to provide a system in which applications can remain essentially independent and yet still be able to effectively communicate and cooperate with each other.

Other features, objects and advantages of the present invention will be understood by those of ordinary skill in the art after reading the following descriptions of a present implementation of the present invention and after examining the drawing, wherein:

BRIEF DESCRIPTION OF THE DRAWING

FIGS. 1A, 1B and 1C are diagrammatic representations of information processing systems incorporating the present invention;

FIG. 2 is a diagrammic representation of a system database of the present invention;

FIG. 3 is a diagrammic representation of an object manager table of the present invention;

FIG. 4 is a diagrammic representation of an object prototype table of the present invention;

FIG. 5 is a diagrammic representation of an object catalog of the present invention;

FIG. 6 is a diagrammic representation of an object table of the present invention;

FIG. 7 is a diagrammic representation of a link table of the present invention;

FIG. 8 is a diagrammic representation of a various data structures involved in links of the present invention;

FIG. 9 is a diagrammic representation of a data exchange of the present invention, including a matchmaker of the present invention; and

FIGS. 10A and 10B are diagrammic representations of a resource and a resource editor of the present invention.

DETAILED DESCRIPTION

The following description presents the structure and operation of a computer system incorporating a presently preferred embodiment of the present invention.

Outline of Detailed Description

1 Concepts . . .

1.1 Objects and Object Managers . . .

1.1.1 An Object Type: Folder

1.2 Links . . .

1.3 Profiles . . .

1.4 Resources . . .

1.5 Operating System and Routine Packs . . .

2 Architectural Overview . . .

3 Objects and Files . . .

4 Data Integration . . .

4.1 Appearance to User in Destination Object .

4.2 An Example Illustrating Certain Data Integration Concepts . . .

5 Links . . .

5.1 Link Updating . . .

5.1.1 When Do Updates Occur?

5.1.2 A Link Update Operation May Require Recursion

5.2 Copying Data Having Embedded Links . . .

5.3 Link Markers . . .

5.4 Link Specifications . . .

5.5 Freezing Objects and Links . . .

6 Physical Organization (FIGS. 1A, 1B, and 1C) . . .

7 Some Elements of an Illustrative System . . .

8 System Data Structures . . .

8.1 System Database . . .

8.1.1 Object Type Table

8.1.2 Object Manager Table

8.1.3 Object Prototype Table

8.1.4 Customization Table

8.1.5 Library Table

8.1.6 Volume Table

8.1.7 System Configuration Table

8.2 Object Catalog . . .

8.2.1 Object Table

8.2.2 Link Table

8.2.3 File List Table

8.2.4 Folder Table

8.2.5 Field WIT File

8.2.6 Object WIT File

8.2.7 Deleted Objects Table

8.3 Link Parallel Files . . .

9 Object Manager Invocation . . .

9.1 Invocation by Direct use of the Kernel . . .

9.2 Startup Requests . . .

9.3 Invocation by APPACK . . .

10 Object Manager Table (FIG. 3) . . .

11 Object Prototype Table (FIG. 4) . . .

12 Object Catalog (FIGS. 5, 6, and 7) . . .

12.1 Catalog Server Process . . .

13 Links and Link Parallel Files (FIG. 8) . . .

14 Copy, Move and Share 106 . . .

15 The Matchmaker . . .

15.1 Matchmaker Purpose and General Operation . . .

15.2 Matchmaker Protocols . . .

15.2.1 Source Protocol

15.2.2 Place Protocol

15.2.3 Processing UNDO after an Interobject MOVE Operation

16 Data Interchange (FIG. 9) . . .

17 Resources . . .

17.1 Resource Files . . .

17.2 Resources (FIG. 10A) . . .

17.3 Resource Editor (FIG. 10B) . . .

18 Resource Customization . . .

18.1 General Customization by Means of Customized Resources . . .

18.2 Customization IDs . . .

19 APPACK Function Calls . . .

19.1 Invocation Services . . .

19.1.1 APrgstart()--Issue A Start . Reguest

19.1.2 APrgedit()--Issue An Edit Reguest

19.1.3 APrgread()--Issue A Read Reguest

19.1.4 APrgrun()--Issue A Run Reguest

19.1.5 APrgcreate()--Issue A Create Request

19.1.6 APrgchangelink()--Issue A Change Link Reguest

19.1.7 APrgprint()--Issue A Print Reguest

19.1.8 APrgupdate()--Issue A Link Update Reguest

19.1.9 APrgcopy()--Copy An Object

19.1.10 APrgdeletelink()--Delete A Link

19.1.11 APrgrelocate()--Relocate An Object

19.1.12 APrgimport()--Import A Foreign Object

19.1.13 APinvoke()--Invoke An Application

19.2 Operation Support . . .

19.2.1 APinit()--Initialize Application Reguest Processing

19.2.2 APreply()--Reply To A Reguest

19.2.3 APevinit()--Initialize APPACK Event Specification

19.2.4 APevaction()--Set Action Code For APPACK Events

19.2.5 APevremove()--Remove APPACK Event Specification

19.2.6 APmsgtest()--Test An APPACK Message Event

19.2.7 APrioinit()--Get A RIOID For An Active Operation

19.2.8 APmsgwait()--Wait For An APPACK Message

19.2.9 APoprequest()--Send An Operation Reguest

19.2.10 APmsgrequest()--Interpret A Request Message

19.2.11 APopfinish()--Terminate An Operation

19.3 Matchmaker Operations . . .

19.3.1 APmmreserve()--Reserve The Matchmaker For An Operation

19.3.2 APmmpost()--Post An Operation On The Matchmaker

19.3.3 APmmconnect()--Connect To Matched Application

19.4 Link Interchange . . .

19.4.1 LNXpinit()--Start Building Link Stream

19.4.2 LNXprestart()--Reset Stream To Link

19.4.3 LNXplink()--Put A Link Into The Stream

19.4.4 LNXpnewlink()--Put A New Link Into The Stream

19.4.5 LNXpfinish() Finish Building Link Stream

19.4.6 LNXginit()--Start Reading Link Stream

19.4.7 LNXgrestart()--Reset Stream To Link

19.4.8 LNXglink()--Get The Next Link In The, Stream

19.4.9 LNXgpeek()--Look At The Next Link In The Stream

19.4.10 LNXgskip()--Skip The Next Link In The Stream

19.4.11 LNXgfinish()--Finish Reading Link Stream

19.5 Text Interchange . . .

19.5.1 TXXpinit()--Start Building Text Stream

19.5.2 TXXprestart()--Reset Stream To Text

19.5.3 TXXpstring()--Put Text String Into The Stream

19.5.4 TXXpchar()--Put Single Character Into The Stream

19.5.5 TXXpfont()--Change Current Font

19.5.6 TXXpattrs()--Set Text Attributes 182

19.5.7 TXXpdiacritic()--Insert Diacritic Mark

19.5.8 TXXpstrikethru()--Set Strike Thru Character

19.5.9 TXXpscript()--Set Script Offset

19.5.10 TXXpvertical()--Put Vertical Move Down Command

19.5.11 TXXphorizontal()--Put Horizontal Move Command

19.5.12 TXXpspacing()--Put Interline Spacing Command

19.5.13 TXXplangauge()--Put Change Language Command

19.5.14 TXXplink()--Put A Link Into The Stream

19.5.15 TXXpfinish()--Finish Building Text Stream

19.5.16 TXXginit()--Start Reading Text Stream

19.5.17 TXXgrestart()--Reset Stream To Vanilla Text

19.5.18 TXXgnext()--Get Next Type Of Data In Input Stream

19.5.19 TXXgstringsize()--Get Next String Length

19.5.20 TXXgstring()--Get Text String From The Stream

19.5.21 TXXgchar()--Get Character From The Stream

19.5.22 TXXgfont()--Get The Current Font

19.5.23 TXXgattrs()--Get Text Attributes Mark

19.5.25 TXXgstrikethru()--Get Strike Thru Character

19.5.26 TXXgscript()--Get The Script Offset

19.5.27 TXXgvertical()--Get Vertical Move Down

19.5.28 TXXghorizontal()--Get Horizontal move

19.5.29 TXXspacing()--Get Interline Spacing

19.5.30 TXXglanguage()--Get Change Language Command From The Stream

19.5.31 TXXgfinish()--Finish Reading Text Stream

19.6 Record Interchange . . .

19.6.1 REXpinit()--Start Building Vanilla Record Stream

19.6.2 REXprestart()--Reset Stream to Vanilla Record

19.6.3 REXpheader()--Build a Header Record

19.6.4 REXprinit()-Start Record Descriptor

19.6.5 REXpfdesc()--Build Field Descriptor

19.6.6 REXprfini()--End Record Descriptor

19.6.7 REXpdinit()--Start Data Record

19.6.8 REXpdata()--Build Data Field

19.6.9 REXpdfini()--End Data Record PG,22

19.6.10 REXpfinish()--Finish Building Vanilla Record Stream

19.6.11 REXginit()--Start Reading Vanilla Record Stream

19.6.12 REXgrestart()--Reset Stream to Vanilla Record

19.6.13 REXgtype()--Get Next Record Type

19.6.14 REXgheader()--Get Header Record Information

19.6.15 REXgfdesc()--Get Next Field Descriptor

19.6.16 REXgdata()--Get Next Data Field

19.6.17 REXgnext()--Skip to Next Record Type

19.6.18 REXgfinish()--Finish Reading Vanilla Record Stream

RESPACK Function Calls . . .

20.1 Resource File Access Functions . . .

20.1.1 RESfopen()--Open a Resource File

20.1.2 RESfinit()--Open a List of Resource Files

20.1.3 RESfclose()--Close a Resource Files

20.2 Resource Access Functions . . .

20.2.1 RESget()--Get a Resource

20.2.2 RESmget()--Get Multiple Resources

20.2.3 RESpoint()--Get a Pointer to a Resource

20.2.4 RESrelease()--Release a Resource

20.2.5 RESread()--Read a Resource

20.2.6 RESlookup()--Find Resource with Given Name

20.2.7 RESgtinfo()--Get Information About Resource

20.3 Resource File Management Functions . . . File

20.3.2 RESfedit()--Modify a Resource File

20.3.3 RESfview()--Peruse a Resource File

20.3.4 RESfcommit()--Commit Modifications to File

20.3.5 RESgtfinfo()--Get Information About File

20.3.6 RESptfinfo()--Put Information About File

20.3.7 RESavail()--Get Unused Resource ID

20.3.8 RESgtnext()--Get Next Resource Information

20.3.9 RESgtprev()--Get Previous Resource Information

20.3.10 REScheckpt()--Checkpoint Resource File Updates

20.3.11 RESrevert()--Revert to Last Checkpoint

20.3.12 RESfreeze()--Freeze a Resource File Version

20.3.13 RESgtfver()--Get Resource File Version Number

20.3.14 RESptfver()--Put Resource File Version Number

20.4 Resource Editing Functions . . .

20.4.1 RESrdcur()--Read Current Version of Resource

20.4.2 RESgtcur()--Get Current Resource Information

20.4.3 REScreate()--Create a Resource

20.4.4 RESwrite()--Write a Resource

20.4.5 RESrewrite()--Overwrite a Resource

20.4.6 RESptinfo()--Put Information About Resource

20.4.7 RESmove()--Move Resource to New Location

20.4.8 RESptnum()--Renumber a Resource

20.4.9 RESmerge()--Merge a Resource List into a File

20.4.10 RESdelete()--Delete a Resource

20.5 Resource Index Functions . . .

20.5.1 RESixinit()--Start Building a Resource Index

20.5.2 RESixprep()--Begin Modifying an Existing Index

20.5.3 RESixadd()--Add a Resource Index Entry

20.5.4 RESixdelete()--Delete a Resource Index Entry

20.5.5 RESixfini()--Finish Building a Resource Index

20.5.6 RESixlookup()--Look up a Resource Index Entry

20.5.7 RESixulookup()--Look up a USHORT Entry

20.5.8 RESixllookup()--Look up a ULONG Entry

20.5.9 RESixslookup()--Look up a String Entry

20.5.10 RESixufind()--Find a USHORT Entry

20.5.11 RESixlfind()--Find a ULONG Entry

20.5.12 RESixsfind()--Find a String Entry

20.5.13 RESixget()--Get an Entry in a Resource Index

20.5.14 RESixindex()--Get an Entry in a Resource Index

20.5.15 RESixinfo()--Get Info on a Resource Index

20.6 Batch Style Resource Creation Functions

20.6.1 RESccreate()--Create a Batch Style Resource File

20.6.2 REScadd()--Add a Resource to a Resource File

20.6.3 REScclose()--Finish Resource File Building

20.7 User Profile Support Functions . . . ID

20.7.2 RESsupedit()--Edit Resources in a Profile

1 Concepts

1.1 Objects and Object Managers

The system of the present invention is a member of the general class of systems described as "object based". That is, information is stored in structures referred to as "objects". In the implementation of the present preferred embodiment most objects each correspond to one or more files of a conventional computer file system.

Further with regard to objects, the system of the present invention allows the use of an essentially unlimited variety of object "types", including the type previously described as a folder, wherein there may be a type of object for each form of data or information or operation to be performed by the system. That is, the system of the present invention defines only the minimal interface between an object and the system and does not define the internal structure or form of any object. As such, an object within the system of the present invention may be regarded as a general purpose container for data, programs or other information, with the internal structure or form of a particular object being defined by the requirements of the operation to be performed or the type of data or information to be stored therein.

Programs for operating upon objects are known as "object managers" or are sometimes referred to as "editors", "applications programs", or "applications". The term "application" is also used to refer to a collection of object managers that operate on a single object type. Each type of object has associated with it at least one object manager that is designed or intended as the primary means for operating upon the data or information stored in that type of object. For example, the system may support a "document type" object for word processing and there will be a word processing object manager associated with that object type. Similarly, a "data base type" object will have associated with it a data base object manager, which is the primary means for operating upon or with the data stored in the data base type object.

It should be noted, however, that the object managers for operating with a particular type of object are not limited to the primary object manager for that object type. Moreover, the particular object manager invoked to operate upon a particular object may depend upon the type of operation to be performed. The system of the present invention provides for a plurality of object managers to operate with any given object type and certain object managers, for example, certain utilities, may operate with more than one type of object. The primary object manager is simply the object manager which is invoked by default for operations upon a particular object type if the user does not select a different program.

Although typically an object manager will operate on the data of a single type of object, in certain cases it may be desirable to arrange a program to be an object manager for more than one object type. Further, there are various utility programs that perform operations that do not interpret object data (e.g. file copy) and that therefore can be used with various types of objects.

1.1.1 An Object Type: Folder

Folders are used as an organizational tool. Folder-type objects are used primarily for the links they contain. For example, group of objects can be logically associated together by all being linked to a single folder object. Like any object, a folder can itself be linked into a folder. Associated with each folder is a file, which can contain information such as a user's comments about the purpose of the folder, instructions on what to do with the objects in the folder, etc. Often there will be no such data, as a typical folder's significance is only the list of objects linked to it; in this case, essentially all there is to the folder is its entries in the object catalog, primarily the entries in the Link Table.

Folders need no link markers because the links are not embedded in any data. Order among the links in a folder i