Object-oriented notification framework system

A system for an object based notification system. The notification system is designed in a flexible manner to support change notification in an object-oriented operating system. The change notification includes a memory for storing connection information including notification routing information and connection registration information. The connection registration information is stored in a connection object of the object-oriented system and the notification system updates the connection object with registration information indicative of enablement or disablement of notification. Then, when a notification event is detected, the object-oriented operating system selectively notifies objects in the system based on the connection registration information stored in the connection object in the memory of the computer system.

FIELD OF THE INVENTION 
This invention generally relates to improvements in display systems and 
more particularly to global notification of changes occurring in a system. 
BACKGROUND OF THE INVENTION 
Among developers of workstation software, it is increasingly important to 
provide a flexible software environment while maintaining consistency in 
the user's interface. An early attempt at providing this type of an 
operating environment is disclosed in U.S. Pat. No. 4,686,522 to Hernandez 
et al. This patent discusses a combined graphic and text processing system 
in which a user can invoke a dynamic object at the location of the cursor 
and invoke any of a variety of functions from the object. This type of 
natural interaction with a user improves the user interface and makes the 
application much more intuitive. 
For a system to be intuitive to a user, system changes must be communicated 
in a consistent manner regardless of what application is currently active. 
None of the prior art references applicant is aware of provides the 
innovative hardware and system software features which enable all 
applications to obtain system changes through a generic framework for 
notification. 
SUMMARY OF THE INVENTION 
Accordingly, it is a primary objective of the present invention to provide 
an object based system with a generic framework for notification. Each 
object contains status information determinative of the object's state 
(enabled/disabled), its name, its associated graphic, and whether its 
appearance is currently valid. 
Next, the invention queries a command object for notification. Each command 
object has four methods to connect for different types of notifications: 
i) notifications that affect its name, 
ii) notifications that affect its graphic, 
iii) notifications that affect whether its active, and 
iv) notifications that affect any data it provides. 
In this case, the object item just created for the command connects for 
active notification. It does this by passing a connection object to the 
notification system. The command is then responsible for connecting the 
connection object to notifiers affecting whether the command is active. 
Then, the object system queries the command for the enabled state before 
presenting the object item on the display. This processing is accomplished 
by examining the current system state to ascertain if the function is 
active in the current context. Then, the internal state of the object item 
is updated and the object item is displayed based on the appropriate 
appearance state (grayed out or normal). 
When a user invokes a command from an object item, control or direct 
manipulation of an object, a document state is modified and notification 
of the event is sent to the system. This event automatically informs any 
active object items and assures current status information is consistent 
across the operating environment. The notification message includes the 
name of the change and a pointer to the object that sent the notification 
message.

DETAILED DESCRIPTION OF THE INVENTION 
The invention is preferably practiced in the context of an operating system 
resident on a personal computer such as the IBM.RTM. PS/2.RTM. or 
Apple.RTM. Macintosh.RTM. computer. A representative hardware environment 
is depicted in FIG. 1A, which illustrates a typical hardware configuration 
of a workstation in accordance with the subject invention having a central 
processing unit 10, such as a conventional microprocessor, and a number of 
other units interconnected via a system bus 12. The workstation shown in 
FIG. 1A includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 
16, an I/O adapter 18 for connecting peripheral devices such as disk units 
20 to the bus, a user interface adapter 22 for connecting a keyboard 24, a 
mouse 26, a speaker 28, a microphone 32, and/or other user interface 
devices such as a touch screen device (not shown) to the bus, a 
communication adapter 34 for connecting the workstation to a data 
processing network and a display adapter 36 for connecting the bus to a 
display device 38. The workstation has resident thereon an operating 
system such as the IBM OS/2.RTM. operating system or the Apple 
System/7.RTM. operating system. 
The subject invention is a new object-oriented system software platform 
comprised of an operating system and development environment designed to 
revolutionize personal computing for end-users, developers, and system 
vendors. The system is a complete, standalone, native operating system and 
development environment architected from the ground up for 
high-performance personal computing. The invention is a fully 
object-oriented system including a wealth of frameworks, class libraries, 
and a new generation object programming environment, intended to improve 
fundamentally the economics of third party application software 
development. The subject invention is a fully portable operating system. 
Traditional operating systems provide a set of services which software 
developers can use to create their software. Their programs are very 
loosely integrated into the overall operating system environment. For 
example, DOS applications take over the entire machine. This means that as 
far as the user is concerned, the application is the operating system. In 
Macintosh.RTM. and Windows operating systems, applications feel and look 
similar and they typically support cutting and pasting between 
applications. This commonalty makes it easier for users to use multiple 
applications in a single environment. However, because the commonalty is 
not factored into a set of services and frameworks, it is still very 
difficult to develop software. 
In the subject invention, writing an "application" means creating a set of 
objects that integrate into the operating system environment. Software 
developers rely on the operating system for both a sophisticated set of 
services and a framework to develop software. The frameworks in the 
subject invention provide powerful abstractions which allow software 
developers to concentrate on their problem rather than on building up 
infrastructure. Furthermore, the fundamental abstractions for the software 
developer are very close to the fundamental concepts that a user must 
understand to operate her software. This architecture results in easier 
development of sophisticated applications. 
This section describes four steps to writing software employing the subject 
invention. A user contemplating the development of an application is 
typically concerned with the following questions: 
.smallcircle. What am I modeling? 
For a word processor, this is the text I am entering; for a spreadsheet, it 
is the values and formulas in the cells. 
.smallcircle. How is the data presented? 
Again, for a word processor, the characters are typically displayed in a 
what-you-see-is-what-you-get (wysiwyg) format on the screen with 
appropriate line and page breaks; in a spreadsheet it is displayed as a 
table or a graph; and in a structured graphics program (e.g. MacDraw), it 
is displayed as a set of graphics objects. 
.smallcircle. What can be selected? 
In a word processing application, a selection is typically a range of 
characters; in a structured graphics program it is a set of graphic 
objects. 
.smallcircle. What are the commands that can operate on this selection? 
A command in a word processor might be to change the style of a set of 
characters to bold. A command in a structured graphic program might be to 
rotate a graphic object. FIG. 1B is an illustration of a display in 
accordance with the subject invention. A command is illustrated at 41 for 
bringing a picture to the front of a display. A presentation of graphic 
information is illustrated at 40. Finally, a selection of a particular 
graphic object, a circle, is shown at 42. 
A developer must answer the same four questions asked by the user. 
Fortunately, the subject invention provides frameworks and services for 
addressing each of these four questions. The first question that must be 
answered is: What am I modeling? In a word processing program, the data 
includes the characters that make up a document. The data in a spreadsheet 
includes the values and formulas in the cells. In a calendar program, the 
data includes the times and appointments associated with a given day. The 
invention provides facilities that help to model data. There are classes 
for modeling specific data types including: text, structured graphics, 
sound and video. In addition to these specific classes, the invention 
provides a number of other abstractions that support problem modeling, 
including: collection classes, concurrency control, recovery framework, 
and the C++ language. The class that encapsulates the data model for a 
particular data type provides a specific protocol for accessing and 
modifying the data contained in the data encapsulator, support for 
overriding a generic protocol for embedding other data encapsulators and 
for being embedded in other data encapsulators, generating notification to 
all registered objects when the data changes, and overriding a generic 
protocol for creating presentations of the data. 
The next question that must be answered is: how is the data presented? In a 
structured graphic program, the set of graphic objects are typically 
rendered on a canvas. In a spreadsheet, it is typically a table of cells 
or a graph; and in a presentation program it is a set of slides or an 
outline. The subject invention provides a "view" of the data contained in 
a data encapsulator. The view is created using a "view system" and graphic 
system calls. However, playing a sound or video clip is also considered a 
presentation of the data. 
Next: what can be selected? In a word processing program, a selection is a 
range of characters; in a structured graphics program, it is a set of 
graphics objects; and in a spreadsheet it is a range of cells. The 
invention provides selection classes for all of the fundamental data types 
that the system supports. The abstract baseclass that represents a 
selection made by a user provides an address space independent 
specification of the data selected. For text, this would be a numeric 
range of characters rather than a pair of pointers to the characters. This 
distinction is important because selections are exchanged between other 
machines when collaborating (in real-time) with other users. The baseclass 
also overrides a generic protocol for creating a persistent selection 
corresponding to this selection. Persistent selections are subclasses of 
an anchor object and may be heavier weight than their corresponding 
ephemeral selections because persistent selections must survive editing 
changes. For example, a persistent text selection must adjust itself when 
text is inserted before or after it. Anchors are used in the 
implementation of hypermedia linking, dataflow linking and annotations. 
The baseclass also provides an override generic protocol for absorbing, 
embedding and exporting data contained in a data encapsulator. Baseclasses 
are independent of the user interface technique used to create them. 
Selections are typically created via direct manipulation by a user (e.g. 
tracking out a range of text or cells) but can be created via a script or 
as a result of a command. This orthogonality with the user interface is 
very important. Baseclasses also provide specific protocol for accessing 
the data encapsulator. There is a very strong relationship between a 
particular subclass of the encapsulator class and its subclass of a model 
selection class. 
Finally: what are the commands that can operate on this selection? In a 
word processing program, a command might change the style of a selected 
range of characters and in a structured graphics program, a command might 
rotate a graphic object. The subject invention provides a large number of 
built-in command objects for all of the built-in data types as well as 
providing generic commands for Cut, Copy, Paste, Starting HyperMedia 
Links, Completing Links, Navigating Links, Pushing Data on Links, Pulling 
Data on Links, as well as many user interface commands. The abstract 
baseclass that represents a command made by the user is responsible for 
capturing the semantics of a user action, determining if the command can 
be done, undone, and redone. Command objects are responsible for 
encapsulating all of the information necessary to undo a command after a 
command is done. Before a command is done, command objects are very 
compact representations of a user action. The baseclass is independent of 
the user interface technique used to create them. Commands are typically 
created from menus or via direct manipulation by the user (e.g. moving a 
graphic object) but could be created via a script. This orthogonality with 
the user interface is very important. 
BENEFITS OF FRAMEWORKS 
The benefits of plugging into the abstractions in the invention are greater 
than providing a conceptual model. Plugging into the framework provides 
many sophisticated features architected into the base operating system. 
This means that the framework implements major user features by calling 
relatively small methods. The result is that an investment in coding for 
the framework is leveraged over several features. 
MULTIPLE DATA TYPES 
Once a new kind of data is implemented, the new data type becomes a part of 
the system. Existing software that can handle data encapsulators can 
handle your new data type without modification. This differs from current 
computer systems, such as the Macintosh computer system. For example, a 
scrapbook desk accessory can store any kind of data, but it can only 
display data that has a text or quickdraw picture component. In contrast, 
the subject invention's scrapbook displays any kind of data, because it 
deals with the data in the form of an object. Any new data type that is 
created behaves exactly like the system-provided data types. In addition, 
the data in the scrapbook is editable since an object provides standard 
protocol for editing data. 
The scrapbook example highlights the advantages of data encapsulators. If 
software is developed such that it can handle data encapsulators, an 
application can be designed to simply handle a new data type. A new 
application can display and edit the new kind of data without 
modification. 
MULTI-LEVEL UNDO 
The invention is designed to support multi-level undo. Implementing this 
feature, however, requires no extra effort on the part of a developer. The 
system simply remembers all the command objects that are created. As long 
as the corresponding command object exist, a user can undo a particular 
change to the data. Because the system takes care of saving the commands 
and deciding which command to undo or redo, a user does not implement an 
undo procedure. 
DOCUMENT SAVING, RELIABILITY, AND VERSIONING 
A portion of the data encapsulator protocol deals with filing the data into 
a stream and recreating the data at another place and/or time. The system 
uses this protocol to implement document saving. By default, a user's data 
objects are streamed to a file when saved. When the document is opened, 
the data objects are recreated. The system uses a data management 
framework to ensure the data written to disk is in a consistent state. 
Users tend to save a file often so that their data will be preserved on 
disk if the system crashes. The subject invention does not require this 
type of saving, because the system keeps all the command objects. The 
state of the document can be reconstructed by starting from the last disk 
version of the document and replaying the command objects since that point 
in time. For reliability, the system automatically logs command objects to 
the disk as they occur, so that if the system crashes the user would not 
lose more than the last command. 
The invention also supports document versioning. A user can create a draft 
from the current state of a document. A draft is an immutable "snapshot" 
of the document at a particular point in time. (One reason to create a 
draft is to circulate it to other users for comments.) The system 
automatically takes care of the details involved with creating a new 
draft. 
COLLABORATION 
As mentioned above, a document can be reconstructed by starting with its 
state at some past time and applying the sequence of command objects 
performed since that time. This feature allows users to recover their work 
in the case of a crash, and it can also be used to support real-time 
collaboration. Command objects operate on selections, which are 
address-space independent. Therefore, a selection object can be sent to a 
collaborator over the network and used on a remote machine. The same is 
true of command objects. A command performed by one collaborator can be 
sent to the others and performed on their machines as well. If the 
collaborators start with identical copies of the data, then their copies 
will remain "in sync" as they make changes. Creating a selection is done 
using a command object, so that all collaborators have the same current 
selection. 
The system uses a feature known as "model based tracking" to perform mouse 
tracking on each collaborator's machine. The tracker object created to 
handle a mouse press creates and performs a series of incremental commands 
as a user moves the mouse. These commands are sent to collaborators and 
performed by each collaborator. The result is that each collaborator sees 
the tracking feedback as it occurs. The system also establishes a 
collaboration policy. A collaboration policy decides whether users are 
forced to take turns when changing data or can make changes freely. The 
invention handles the mechanics of collaboration which removes the 
responsibility from an application developer. 
SCRIPTING 
Designing a system to manage the sequence of command objects also makes it 
possible to implement a systemwide scripting facility. The sequence of 
command objects is equivalent to a script of the local actions. The 
scripting feature simply keeps track of command objects applied to any 
document. The scripting facility also uses selection objects in scripts. 
This feature provides customization of a script by changing the selection 
to which the script applies. Since command objects include a protocol for 
indicating whether they can apply to a particular selection, the system 
ensures that a user's script changes are valid. 
HYPERMEDIA LINKING 
Persistent selections, also known as anchors, can be connected by link 
objects. A link object contains references to the two anchors that form 
its endpoints. To the system, the link is bidirectional; both ends have 
equal capabilities. Certain higher-level uses of links may impose a 
direction on the link. The single link object supports two standard 
features: navigation and data flow. A user can navigate from one end of 
the link to the other. Normally, this will involve opening the document 
containing the destination anchor and highlighting the persistent 
selection. The exact behavior is determined by the anchor object at the 
destination end. For example, a link to an animation may play the 
animation. A link to a database query may perform the query. 
Links also facilitate data flow. The selected data at one end of the link 
can be transferred to the other end to replace the selection there. In 
most cases, the effect is the same as if the user copied the selection at 
one end, used the link to navigate to the other end, and pasted the data. 
The system takes care of the details involved with navigating from one end 
of a link to the other (e.g., locating the destination document, opening 
it, scrolling the destination anchor into view, etc.). Similarly, the 
system handles the details of transferring data across the link. The 
latter is done using the selection's protocol for accessing and modifying 
the data to which it refers. 
ANNOTATIONS 
The invention supports a system-wide annotation facility. This facility 
allows an author to distribute a document draft for review. Reviewers can 
attach posted notes to the document, and when done, return the document to 
the author. The author can then examine the posted notes and take action 
on each. (An author can also create posted notes in the document.) A 
reviewer need not have the same software as the author. Instead, the 
reviewer can use a standard annotation application. This application reads 
the data from the author's draft, and creates an annotatable presentation 
of the data. (Creating such a presentation is part of the standard data 
encapsulator protocol.) 
The reviewer can create selections in the document, and link posted notes 
to the selection. The link between the posted note and selection allows 
the system to position the posted note "near" the selection to which it 
refers. The links also make the annotation structure explicit, so that the 
system can implement standard commands to manipulate annotations. The 
contents of the posted note can be any data type implemented in the 
system, not simply text or graphics. The contents of a note is implemented 
using a data encapsulator, and opening a note results in creating an 
editable presentation on that data. 
DATA REPRESENTATION 
Data representation is concerned with answering the question of what is the 
data that I am modeling? The subject invention provides facilities that 
help to model data. There are classes for modeling specific data types, 
including: text, structured graphics, sound and video. In addition to 
these specific classes, the invention provides a number of other 
abstractions that help to model a problem: the collection classes, the 
concurrency control and recovery framework, and the C++ language itself. 
In the subject invention, the class that encapsulates the data model for a 
particular data type is a subclass of the encapsulator class. 
THE ENCAPSULATOR