1. Field of the Invention
This invention generally relates to program application microprocessor instructions and, more particularly, to a method for initializing or refreshing a program application that includes instructions with interdependent volatile data.
2. Description of the Related Art
Conventional software programs must have an initialization function that takes care of all initialization aspects of the program. If the program data items have fixed values, initialization is relatively straightforward. If the function operates on all volatile pieces of datum that need to be updated, it must first compute their values to obtain current states. An initialization procedure also needs to be responsive to any new data items that are introduced into the system. Therefore, when a new data item is added, the function needs to be revisited, recoded, and naturally recompiled. Recoding can be a significant problem if there is a dependency between volatile data items requiring that the data items be calculated in a specific order.
Conventional solutions depend on a hierarchy of objects, having pointers to contained objects, which in turn have pointers to more contained objects. Thus, in conventional systems, all object need to be created in order to revive all values.
It would be advantageous if an initialization application for a software program could be easily configured with interdependent volatile data values.
This application describes a method for updating the state of the system. A system, or program application can have many pieces of data. Some of them can be persisted, with a fixed value, because they are immutable. For example, persisted data can be a profile name or copier model number. But some pieces of data are volatile, in that their state should not be saved. That is, the volatile data states need to be updated from time-to-time. For example, a network-connected device may need to update its Internet protocol (IP) address in a dynamic host configuration protocol (DHCP) environment.
Accordingly, an initialization application method is provided. The method comprises: reviving a program application with uninitialized data objects; accessing an initialization application data, including object identification (OID), for creating object data; assembling the data into a tree structure; reading the OID from a node in the initialization application assembled tree structure; in response to reading the OID, creating an object with a position parameter; passing the node location to the object position; populating the object location with a value; and in response to populating the object location with a value, initializing a program application.
For example, the method may generate a volatile value for the object, and populate an object first location with the volatile value. The method may also read a persistent value, and insert the persistent value into an object second location. The program application built can be for a multifunctional peripheral (MFP) application controlling the functions of a network-connected MFP. Then, volatile values may be generated for objects such as a domain name system (DNS) server addresses, IP addresses, or profile destinations.
In another aspect, the method reads a priority associated with sibling nodes embedded in the data node, and accesses sibling nodes in a BFS fashion. That is, higher priority sibling nodes are accessed prior to lower priority sibling nodes. In a different aspect, the tree structure of data nodes is a component object model (COM) software architecture, and the OID embedded in the data nodes is a global unique identifier (GUID) used to create the object in a late bind fashion.
Additional details of the above-described method and a system for initializing an MFP program application are provided below.
A program application (PA) 114 of microprocessor executable instructions resides in memory 106 with data objects generated in response to populating the initialization application object positions with volatile values. An assembly application (AA) 116 may also reside in memory 106 for loading data, including OIDs, from memory in response to the program revival command on line 110. The assembly application assembles the data into a tree structure, and generates the initialization application. Alternately, the data 120 is stored in a tree structure so that no assembly is required.
The initialization application can also work with fixed value data. For example, in
Alternately stated, the location of the node in the tree is predefined. But the location, or cue of how to generate the object from scratch, is identified by the GUID. There is a database with paths in the memory. The GUID constitutes the key, the query of which will retrieve the path. GUID is used to create the object, and pass the created object the location in the tree. That is, each node corresponds to an object annotated by a GUID (OID) value, so that it can be created. Each node has a priority tag, so that order of creation can be determined.
The initialization application follows a path associated with the OID to a set of instructions in memory and, in response to executing the instructions, creates the object. At the end of the path, a program is found. Typically, the program is a dynamic link library (DLL), but it can also be EXE file, or any set of computer instructions that can be executed. The system runs the program, and gives it instructions or call functions such as initialize(param:TreePath), or ReviveData(param:DNSServer). A DLL is an executable program module in Microsoft Windows that is not launched by the user. Rather, they are called for by an executable program or by other DLLs. One DLL can be shared by many applications. In a UNIX operating system, a “shared library” performs a function equivalent to a DLL.
As mentioned above, the state of the program/application is maintained in a tree structure, such as in extensible markup language (XML). Every object represents a node in the tree that may have sub-elements (child nodes) that comprise the data of the object. An object having sub-objects can be depicted as a node in the tree (e.g., copier node) having child nodes of IP address, DNS servers, and profile nodes, which in turn have sub-nodes of name, destination, and type (see
As shown in
Thus, every node has a cue associated with the corresponding object, telling the system how to create the object. Each node in the tree also has a priority property that tells the system in what order to create the siblings. And so, one small and relatively simple recursive function can traverse the tree in a BFS fashion, create the objects, and give instructions to the objects for updating themselves. Adding a new object to the hierarchy does not entail changing the initialization function, as long as the new object corresponds to the tree conventions stated above. In fact, the initialization function need not be recompiled, as all the decisions are being made at runtime.
Consider an MFP. An MFP has a web page through which a user can change its state. The user can change the DNS servers that the MFP is using. The user runs an application that is using objects to represent MFPs. The application saves its state to the disk. The next time the user launches the application, the state is resurrected from disk. There are fields, however, that may have changed since the last time the program was run, referred to herein as volatile. For example, if the system administrator changes the DNS server addresses on the copier device, then the corresponding fields in the MFP object in the application are out of date, and need be updated. Thus, the initialization application is a scalable system in which objects get instantiated, in order to update the application's infoset.
In
1. Identifying the root of the tree, the root contains information on how to create the corresponding object (e.g., in COM a GUID would be a cue used by the system to create a specific object).
2. Creating the object and passing it to the corresponding node in the tree.
3. Each object does it's own initialization, reviving the missing values for which it's responsible.
4. Enumerating all child nodes and sorting by priority.
5. Recursively instantiating the child objects.
6. Passing child object corresponding child nodes.
Step 602 identifies the root of a tree, the root including cues for the creation of an object. Step 604 instantiates the object. Step 606 passes the object to a corresponding node in the tree. Step 608 revives volatile object values. Step 610 instantiates sibling objects by priority. Step 612 instantiates child nodes in a BFS manner.
Returning to
One advantage this system over conventional solutions is that not all the objects need to be instantiated at all times. Conventional solutions depend on a hierarchy of objects, having pointers to contained objects, which in turn have pointers to more contained objects. Thus, in conventional systems, all object need to be created in order to revive all values. In the present invention system, only objects that have the GUID value in the tree need to be instantiated. The system is able to create every element, without having to know how to create its parent element.
Step 901 (prior to Step 902) accesses a first node in a tree structure of data nodes. Step 902 reads an OID embedded in data at a node location. Step 904 creates an object with a position parameter in response to reading the OID. Step 906 passes the node location to the object position. Referencing Step 901, Step 906 passes the tree first node location to the object position. Step 908 populates the object location with a value. Step 910 initializes a program application in response to populating the object location with a value.
In one aspect, Step 907a generates a volatile value for the object. Then, populating the object location with a value in Step 908 includes populating an object first location with the volatile value. In a different aspect, Step 907b reads a persistent value. Then, Step 908 inserts the persistent value into an object second location.
In some aspects, accessing the first node in the tree structure of data nodes (Step 901) includes accessing sibling and sibling's children nodes in a BFS fashion. That is, Step 901a reads a priority associated with sibling nodes embedded in the data node. Then, Step 901b accesses higher priority sibling nodes prior to accessing lower priority sibling nodes.
In other aspects, creating the object in response to reading the OID in Step 904 includes substeps (not shown). Step 904a follows a path associated with the OID. Step 904b executes a set of object creation instructions in response to following the path.
In one variation of the method, accessing the first node in the tree structure of data nodes (Step 901) includes accessing the first node in a component object model (COM) software architecture. Then, reading the OID embedded in the data node (Step 902) includes reading a global unique identifier (GUID).
In one example, initializing the program application in Step 910 includes building a MFP application controlling the functions of a network-connected MFP. Thus, generating the volatile value for the object in Step 907a includes generating a volatile value for objects such as a DNS server address, IP address, or profile destination.
A system and method have been presented for initializing a system of data objects. Examples of the invention have been given within the context of a network-connected printer. However, the invention is not limited to use in any particular type of device, interface, or device function. Likewise, examples have been given of the invention in the context of a Microsoft Windows operating system. Again, the invention is not limited to any particular operating system. Other variations and embodiments of the invention will occur to those skilled in the art.