 |
Description  |
|
|
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 new 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 types 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
as 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
and 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 diagrammic representations of information
processing systems which may incorporate the present invention;
FIG. 2 is a diagrammic representation of a system database of the present
invention;
FIG. 3 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
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 APrqstart()--Issue A Start Request
19.1.2 APrqedit()--Issue An Edit Request
19.1.3 APrqread()--Issue A Read Request 1
19.1.4 Aprqrun()--Issue A Run Request
19.1.5 APrqcreate()--Issue A Create Request
19.1.6 APrqchangelink()--Issue A Change Link Request
19.1.7 APrqprint()--Issue A Print Request
19.1.8 APrqupdate()--Issue A Link Update Request
19.1.9 APrqcopy()--Copy An Object
19.1.10 APrqdeletelink()--Delete A Link
19.1.11 APrqrelocate()--Relocate An Object
19.1.12 APrqimport()--Import A Foreign Object
19.1.13 APinvoke()--Invoke An Application
19.2 Operation Support
19.2.1 APinit()--Initialize Application Request Processing
19.2.2 APreply()--Reply To A Request
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 APmgtest()--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 Request
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 LNKpnewlink()--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()--Current Change Font
19.5.6 TXXpattrs()--Set Text Attributes
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 TXXplanguage()--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
19.5.24 TXXdiacritic()--Get Diacritic Mark
19.5.25 TXXstrikethru()--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 TXXgspacing()--Get
Interline Spacing
19.5.30 TXXlanguage()--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
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
20 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 File
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
20.3.1 RESfcreate()--Create a Resource 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 RESgtinfo()--Get Information About File
20.3.6 RESptinfo()--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 RESinxinit()--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
20.7.1 RESptcustid()--Set Customization 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 is determined not by the sequence
in which link markers are embedded, but by the values of the Link IDs
stored in the Link Table.
A Folder does not link any data from the objects to which it has links
(i.e., a folder needs no link parallel file). Folders just use links to
represent relationships among whole objects.
Each user of the system has a primary folder. This is the primary means by
which a user gains access to resources of the system. There is a primary
system folder, which is typically linked into each user s primary folder,
giving each user access to certain common system resources. Further, all
of the user primary folders are linked into the system folder.
1.2 Links
While information in the system is primarily contained within objects,
objects, in turn, are related to one another through a mechanism referred
to as "links". A link may be conceptually viewed as a means by which one
object, referred to as a "child" object, is "connected" to another object,
referred to as the "parent" object. Each object is, in some sense, a child
object in that each object always has at least one link to it and is
connected through that link to at least one parent object. In this regard,
and as will be described in the following, each user has at least one
primary parent object to which all other objects associated with that user
are directly or indirectly linked. The terms "parent" and "child" refer to
the direction of a link, are not meant to imply any hierarchy among linked
objects.
It should be noted that, as described in the following descriptions, a link
may also be used to link a portion of a child object to a parent object,
as well as an entire child object. In addition, any number of objects, or
portions of objects, may be chained together through links, and the
sequence and direction of links is no hierarchically limited.
1.3 Profiles
A profile is user-visible information about something, such as a system,
object, or link. The information included in an object profile depends on
the object type. For a document-type object, the object profile includes
some of the information stored in the Object Table along with information
stored in the object itself, such as a font list, global format
information, and printing parameters.
1.4 Resources
A "resource" is data that is used by a program but which is not stored as a
part of the program's executable code. Examples of such data include icons
language dependent text, messages, text fonts, forms, date and time and
presentation formats. A resource is therefore a means for storing such
program data separately and independently from the program with which it
is associated.
The placing of program data in resources allows the information therein to
be customized or changed without affecting the program's executable code.
English, French and German language versions of word processing, data base
and spreadsheet programs, for example, may be generated by simply
providing English, French and German language versions of the
corresponding resources. In each version of the programs only the program
data residing in the associated resource is changed, the executable code
of the programs remain unchanged. In addition, the use of resources allows
object managers and other programs to share common program data, thereby
reducing the sizes and memory requirements of the individual object
managers and other programs.
Storing data in resources also makes possible easy customization for
individual users of the appearance and operation of programs. A
user-specific customized version of a resource can be stored in the user's
user profile. A mechanism is provided by which any customized resources
present in a user profile are automatically substituted for their standard
counterparts automatically (and invisibly to the program using the
resource) when needed by a program.
1.5 Operating System and Routine Packs
Computer systems typically include a group of programs which are referred
to as an operating system. An operating system may be viewed as a
collection of programs which control and facilitate the overall operation
of a system and which provide selected, fundamental, general services and
operations for users of the system. Examples of such operating system
services and operations include process management, event management,
memory management, input/output operations, logical to physical address
translations, graphics/text and display operations, file access and
management operations, and mathematical operations.
In the traditional view of operating systems, all functions and operations
which are not specific, particular or unique to a particular application
program are to be performed by the operating system. In addition, the
traditional view regards the operating system as a tightly integrated and
mutually dependent group of programs and the operating system is generally
designed as a unitary structure of programs in which the designer attempts
to anticipate all functions which may be desired, presently and in the
future, by the applications programmers. Because of the relatively
monolithic nature and complexity of an operating system and the resulting
interrelationships of the programs comprising an operating system, it is
therefore relatively difficult to modify, change, update or add features
to an operating system.
The operating system of the present invention differs from the traditional
operating system in that, firstly, the actual functions and services
performed by the operating system are reduced to the minimum. As will be
described in the following, the operating system of the present system
essentially performs only the process, event and memory management
functions and logical to physical address translations.
Secondly, other functions and services which would normally be performed by
an operating system, together with many functions and operations which
would normally be performed by the application programs themselves, are
performed by libraries of routines. These libraries of routines, referred
to herein as "packs", exist independently of both the operating system and
the application programs. As will be described in the following
descriptions, the routines contained within the packs are comprised of
short, generic, single purpose routines designed to be of wide general
applicability and usefulness for both operating systems services and
application program support functions. Examples of services and functions
performed by pack routines include, but are not limited to, input/output
operations, graphics/text and display operations, file access and
management operations, and mathematical operations.
As will also be described, each pack contains a set of routines or
functions which are related by the type of operation they perform or the
type of object they operate upon. In addition, all routines of a given
pack are provided with a uniform interface, or calling and return
sequences, and the packs are required to conform to a uniform format, in
particular with regard to pack header files and control blocks, that is,
blocks of information regarding the objects controlled by the packs.
The use of packs of routines for many operating system type services and
functions and for many operations normally provided within application
programs greatly enhances the flexibility of the system architecture and
configuration. Functions and services may be added or altered easily and
quickly and without disturbing or otherwise impacting other functions of
the system. In addition, the use of packs reduces the size and complexity
of application programs in that many operations or functions normally
incorporated into each individual application program may now be shared by
many application programs. Also, the use of routine packs with
standardized interfaces facilitates integration of different applications
in that many operations and interfaces to the system, the user, and other
application programs are defined by and conform to the defined,
standardized routine pack interfaces.
In the preferred embodiment, these routines are stored in a shared
subroutine library are dynamically linked as needed at runtime. In some
cases, it may be desirable to include copies of routines from pack
libraries in the executable code of a program; however, this approach
increases the physical size of application programs.
When reference is made in the following discussion to a routine performing
some function, it should be understood that the routine may accomplish
this directly itself, or by making a system call, or by a series of
interprocess communications with another process. For example, the APPACK
routine APinvoke() accomplishes the invocation of an object manager by
communicating with the application manager process which ultimately makes
a system call that results in invocation of an object manager.
2 ARCHITECTURAL OVERVIEW
The present invention involves the manipulation of typed objects. Different
objects are designed to represent different forms of information, such as
the following. Document objects represent text and associated formatting
information. Spreadsheet objects represent mathematical modeling
information. Voice objects represent sound. Image objects represent
photograph-type pictures.
For each type of object there is one or more "object manager" that can
operate on objects of that type. Object managers roughly correspond to
applications programs. For example, there may be spreadsheet program: this
can be understood to be an "application", as distinguished from operating
system program; it can also be understood to be a "manager" or "editor" of
objects of type "spreadsheet".
Because it is an object's object manager(s) that define its structure and
interpretation, the collection of object types is open-ended; existing
types of information can be integrated with future types of information
with the same each with which the existing types are integrated with each
other. A new object type can be added to the system by adding a program
(i.e., an object manager) that can manipulate objects of the new type. The
ability to manipulate the new type of object need only be implemented
once. Having added the new object manager, objects of the new type can be
linked into, exchange data with, and otherwise appear integrated with
objects of pre-existing types without modification to pre-existing object
managers.
A convention that facilitates the open ended integration is that for each
object type there shall be an object manager that will support all of a
standard set of requests. Further, these requests are communicated between
object managers by a single standard protocol that is application
independent. Absolute adherence to this convention is not required.
However, as the number of exceptions increases, the benefit obtained from
this approach to data integration decreases.
If cases arise where the standard requests and protocols do not provide an
adequate degree of integration, private requests and protocols can be
defined to coexist with the standard set. Thus, this open ended approach
defines only the minimum level of integration, without precluding tighter
coupling where appropriate. An example of a case where private protocols
may be appropriate is communication between a spreadsheet application and
a graphing application.
There is a set of Application Integration Services that are available to
all the object managers. These services do not embody any "knowledge" of
any particular types of objects. Rather, the service are used by the
object managers to coordinate their manipulation of the various types of
objects. In particular, these services facilitate bringing to bear an
object manager embodying the appropriate object type specific "knowledge".
Application Integration Services are so named because they are a mechanism
by which an individual application (i.e., object manager) can appear to a
user to integrate its operation and manipulation of data with that of
other applications. To a user, the display of a page of a newsletter
having both text and a picture indicates that the picture and text are
integrated together in a single entity known to the user as a document.
According to the present invention, this effect is accomplished by
operation of two different object managers as coordinated by use of the
Application Integration Services. The newsletter is stored in an object of
type document, which is a type of object designed to store text and
associated formatting information. The particular document object of this
example includes a link to a separate object of type "image", an object
designed to store photograph type pictures. The display of the page is
accomplished by a document object manager retrieving and displaying the
text and an image object manager retrieving and displaying the picture.
The information describing the link to the picture and the operation
required (display) is communicated from the document object manager to the
image object manager with the assistance of the Application Integration
Services.
The computer system of the present illustrative embodiment includes the
ability to run a plurality of programs effectively concurrently. This is
known as multitasking or multiprocessing, and each of the concurrently
executing programs is known as a task or process
In the present system there is an Application Manager process. The
Application Manager spawns the object manager processes. Thus, in general,
the object managers are peers with each other and are children of | | |
