Abstract:
A method for exchanging information between two computer processes wherein the two computer processes deposit and retrieve information into a container rather than exchanging information directly with each other. The container stores the information based on the name of the information assigned by the depositing computer process, and maintains a dictionary of the names of the information contained in the container. Information is retrieved by the retrieving computer process by querying the container for the information by information name.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention pertains to a method by which information may be exchanged between computer processes using a container-based exchange medium. More specifically, the present invention relates to an information exchange method whereby the computer processes, rather than exchanging information directly, exchange information by depositing and/or retrieving information in a container. 
     2. Description of The Related Art 
     Application programs that execute on today&#39;s computing equipment rarely possess all the functionality that is needed for the application program to execute fully. Rather, those application programs rely on external libraries of other programs in order to execute all programs for the functionality that is required. For example, an application program may rely on an external library containing device drivers such as printer drivers or monitor drivers in order to output data, and the application program may rely on the computer operating system, such as DOS, to store and to retrieve information from files. Likewise, the application program may use functionality that is not even present on the computer in which the application program is running; for example, in a network environment, the application program may print information to a printer that is not physically co-located with the computer and which is controlled by an altogether different computer. 
     Traditionally, the mechanism for passing information between the application program and other programs is through shared memory in which both the application program and the other program are aware of the structure of the information stored in the shared memory. For example, to print information on a printer, the application program stores the print information in a pre-designated block of shared memory, and then signals the print driver that the print information is stored in the shared memory. The print driver, knowing the structure by which the print data has been stored in shared memory, retrieves the print information from shared memory and executes printing processing. 
     Such a structured information exchange using shared memory has been found to be unsatisfactory. In particular, the shared memory must be reserved at compile time by the compiler and resolved into specific memory addresses at load time by the operating system loading program. Thus, memory which is potentially used only infrequently may be wasted. 
     Second, both the application program and the other program must have knowledge of the structure of shared memory. For example, if an application program has queried a print driver for the current printer setup and capabilities, the application program must have knowledge of how the printer driver will store that information in memory, for example, fonts first, then paper trays, then collating capabilities, and so on. 
     Finally, direct information exchange using shared memory is inflexible. Once the structure of shared memory is defined, which normally occurs early on in system design, the structure cannot be changed lest the new structure be incompatible with the old structure. Accordingly, as new system capabilities are provided, for example, upgrading a printer to a printer that includes a stapler, those new capabilities cannot be accessed by the application program because there is no provision in the shared memory area for defining the parameters of the new capability. 
     SUMMARY OF THE INVENTION 
     It is the object of the present invention to address the foregoing difficulties. 
     In one aspect, the invention is a method for exchanging information between two computer processes, for example, between a application program such as a word processing program and a print server program that controls printing on a printer, using a container-based exchange wherein the two computer processes deposit and retrieve information into the container rather than exchanging information directly with each other. The container stores the information based on the name of the information assigned by the depositing computer process, and maintains a dictionary of the names of the information contained in the container. Memory is allocated dynamically as information is deposited. Information is retrieved by the retrieving computer process by querying the container for the information by information name. 
     According to this aspect of the invention, a method for exchanging information between first and second computer processes comprises executing the first computer process to set named information values into a container. In response to setting the named information into the container, container processing is executed to store the value of the named information and to update a dictionary of names in the case where the named information is not already in the dictionary. The second computer process is executed to get named information from the container and designates a buffer into which the container places the information value. In response to a command to get named information from the container, container processing is executed to store the value of the named information into the designated buffer by reference to the dictionary of names, or to store an error code in the case where the dictionary of names does not include the requested name. 
     In case the second computer process does not know the names of information stored in the container, the second process can instead request for the first named value stored in the container&#39;s dictionary and then for subsequent values, whereby the second process may interactively proceed through all values stored in the container. 
     By virtue of the foregoing arrangement, memory need not be allocated at compilation time but rather is dynamically allocated during execution. There is no need for the two computer processes to know the structure of a shared memory area because storage and retrieval is based on names of information rather than position. Finally, complete flexibility is offered since any values can be stored in the container rather than only values which may have been designated early on in design. 
     This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiment thereof and to the drawings. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a representational view of a local area network according to the present invention. 
     FIG. 2 is a functional block diagram of network communications between a first computer process comprising an application program executing in a first networked work station, and a second computer process comprising a print server executing in a second networked work station. 
     FIGS. 3 a ,  3   b , and  3   c  are a flow diagram for explaining information exchange according to the invention. 
     FIG. 4 is a view of a dialogue box displayed on the first networked work station. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     FIG. 1 is a representational view of a local area network (“LAN”)  10  according to the invention. As seen in FIG. 1, LAN  10  includes a LAN communication bus  11 , such as Ethernet, for carrying LAN communications among the network devices attached to the bus. A file server  12  is attached to LAN bus  11  and acts as a file manager for receiving, storing, queuing, caching and transmitting files between networked devices. File server  12  typically includes a large capacity memory storage device, such a ten gigabyte hard disc, for performing its file manager duties. File server  12  operates under a network operating system such as Netware®. 
     Also attached to LAN bus  11  are work stations  14 ,  15 ,  16 ,  17 ,  18  and  19  which in this case are shown as personal computing equipment such as IBM PC or PC-compatible computers. Station  14  may be designated as a network administrator work station from which various network functions are controlled. Work stations  15  and  16  are network user work stations and include various application programs such as word processing application programs, spread sheet application programs, optical character recognition application programs, and other information and data processing programs. Those programs may physically be stored in work stations  15  and  16 , or they may be retrieved for execution at those work stations from file server  12 . 
     Work stations  17 ,  18  and  19  are peripheral server work stations and exist primarily to provide network services for the peripherals to which they are connected. Thus, work station  17  is a print server work station and provides network services for printer  21 . Likewise, work station  18  is a scanner server work station and provides network services for scanner  22 , and work station  19  is a facsimile server work station and provides network services for facsimile  23 . Other peripheral devices may also be connected to the network, and it is possible for a single work station to service more than one peripheral device. In particular, it is possible for work station  17  to service more than one printer, and it is also possible, with appropriate equipment, for a single work station to service a variety of different types of devices. 
     While it is ordinarily necessary to provide a dedicated work station to service one or more peripheral devices, in some instances this is not necessary. Thus, for example, printer  25  is connected directly to LAN bus  11  via a network expansion board  26  which provides the necessary print server functions without the necessity of dedicating a work station for those printer services. 
     Other devices may be connected to LAN  10 , and indeed LAN  10  may be connected as part of a wide area network (“WAN”) through various backbone and transponder connectors. These arrangements are well known to those skilled in the art and are omitted in the interest of brevity. 
     FIG. 2 is a functional block diagram showing information exchange according to the present invention. In FIG. 2, information exchange is illustrated between a first computer process such as an application program executing on one of the work stations illustrated in FIG. 1 (here, work station  16 ), and a second computer process such as a print server executing on work station  17 . It is to be understood that the computer processes illustrated in FIG. 2 are representative only; information exchange can take place between any of the devices illustrated in FIG. 1 such as between work stations  15  and  16  or between one of the work stations and either the scanner server work station  18  or the facsimile server work station  19 . Moreover, information exchange shown in FIG. 2 is illustrated between different work stations on a local area network where the need for flexible information exchange is the most critical. It is to be understood, however, that information exchange according to the invention may occur between different computing processes within the same work station, for example, between a word processing application program that is importing numerical data and a spread sheet processing application program which is providing the numerical data. 
     As shown in FIG. 2, information exchanges occur between a first computer process comprising device drivers  31 , which in turn are controlled by an application program  30  executing in work station  16 , and a second computer process comprising a print server  39  executing in print server work station  17 . The precise details of application program  30  that is executing in work station  16  are unimportant to the present invention, and the application program may, for example, be a word processing application program, a spread sheet processing application program, or any other application program. In the course of execution of application program  30 , the services of a peripheral device are required. The application program  30  obtains those services via one of device drivers  31  such as a printer driver, a scanner driver or a facsimile driver. The device driver, in turn, accesses the device through container manager  32  and communicates on LAN bus  11  via network interface  34 . Container manager  32  operates to manage access to a container which may, for example, be stored as a file on file server  12 . 
     In like manner, work station  17  includes a network interface  36  by which it interfaces with LAN bus  11 , a container manager  37  which manages the print server&#39;s access to the container, and the print server  39  which directly controls printer  21 . 
     In general, information exchange between device driver  31  and print server  39  is accomplished through a container into which one of those computer processes deposits named information values and from which the other computer process retrieves information by requesting the value of the named information. For example, device driver  31  may signal print server  39  to provide the setup and control parameters of printer  21 . In response, print server  39  causes container manager  37  to create a container, if one has not already been created by the print server, and to deposit named information values into the container. As named information values are being deposited into the container, the container updates a dictionary of names by which those values may be retrieved. After the container has been filled by printer server  39 , it is delivered across the network to device driver  31  which in turn may retrieve the setup and control parameters by requesting the container to provide those values by name. In response to each such request, the container refers to its dictionary to determine whether the requested name is stored in the container, and if the named information value is stored in the container the container provides the requested information to device driver  31 . If the requested name is not in the container then an error value is returned. The print driver may display the setup and control parameters obtained from the print server and allow the computer operator to modify or change the parameters, whereafter the print driver sets the changed parameters back to the container and advises the print server that the values have been changed. The print server can then retrieve the changed parameters from the container. 
     After the parameters have been received by print driver  31 , the print driver  31  may send a print job back to print server  39  also via a container. In this case, the print driver  31  creates a container, for example, in file server  12 , and sets print job information into the container by name. Print driver  31  then advises print server  39  that a print job is present in the container, whereupon the print server  39  retrieves the print information by name from the container and controls printer  21  to execute the print job. 
     The containers created in this information exchange are objects that contain an indexing mechanism. The indexing mechanism stores the names of different variables present in the container and stores/obtains values corresponding to those variables. Once created, the container need be responsive only to two commands, a “SET” command and a “GET” command, as follows: 
     SET (container_name, name, value, type) 
     GET (container_name, name, buffer, type) 
     where: container_name is the name of the container in which information is to be gotten or set, name is the name of the information value to be stored or retrieved, value is the value of the named information to be stored, type in the case of a SET is the type of information to be stored, and, in the case of a GET is the type of information retrieved from the container, and buffer is a storage area into which the value of the named information is retrieved by the container. Type may be of two types: data-type or container-type. Data-type simply means that an information value is to be stored in the container. Container-type means that a sub-container has been created within the container_name container. 
     In the case of an object oriented programming language (“OOPL”) the container_name value may be omitted since the “SET” (and “GET”, described below) refers to the object being used and container_name is therefore implicit. 
     Container processing in response to a SET command proceeds as follows. First, the container specified by the container_name variable determines whether the name&#39;d information already exists in its dictionary. If the name does not already exist in the dictionary, then the dictionary is updated to include the name, and the associated type is also stored in the dictionary. If type equals “data-type”, then the value of the named information is stored in the container. If type equals “container-type”, then the container creates a new container with the specified name. 
     Processing according to the GET command is as follows. First, the container specified by container_name determines whether the name&#39;d value is in its dictionary. If the name is in the dictionary, then the container stores the value of the name&#39;d information into buffer and stores the type of information into type. On the other hand, if the container_name container&#39;s dictionary does not include name, then the container returns an error code. 
     Preferably, the container is also responsive to at least two other commands, a GET_FIRST command and a GET_NEXT command, as follows: 
     GET_FIRST (container_name, name_buffer, buffer, type); 
     GET_NEXT (container_name, name_buffer, buffer, type). 
     where: name_buffer is a buffer into which the container_name container returns the name of the first name in its dictionary or the next name in its dictionary. The remaining parameters are as described above. 
     The GET_FIRST and GET_NEXT commands allow a computer process to access information in a container without knowing the names of the information stored in those containers. In response to a GET_FIRST command, a container returns the name of the first item of information stored in the container&#39;s dictionary as well as its value and type. In response to a GET_NEXT command, the container returns the next item of named information in its dictionary as well as its value and type. 
     The container may also be provided with other capabilities for allowing access to information in the container. For example, if desired, the container can be made responsive to so-called “wild card” name queries in which the full name is not provided to the container but instead a template of the name, including wild card characters, is provided to the container. Thus, in response to successive issuances of a command like GET (container_name, STAPL?, X1, X2), a container will iteratively sequence through its dictionary and return values of name&#39;d information whose name begins with the characters “STAPL” (such as “STAPLER-PRESENT”, “STAPLE_COUNT”, “STAPLING”, etc.). Embedded wild card characters may also be supported. 
     FIG. 3 is a detailed flow chart showing information exchange according to the invention. Because information exchange according to this example involves three different processings, three different flow columns are illustrated in FIG. 3, the first column showing driver processing, the second column showing server processing and the third column showing container processing. 
     In Step S 01  driver  31  issues a request across LAN bus  11  to server  39  for setup and control parameters. When print server  39  receives the request, the server creates a STATUS container (Step S 02 ). Flow advances to Step S 03  in which for each data-type setup or control parameter, print server  39  SETS the name of the parameter and its value to the STATUS container. For example, if the print server stores print orientation information (portrait or landscape) in a variable named “Portrait/Landscape”, then print server  39  sets that parameter to the STATUS container by issuing the following command: 
     SET (STATUS, portrait/landscape, “portrait”, “data”). 
     Likewise, if print server  39  stores error conditions in a variable named “error_condition,” then if the value of that variable is “none” then print server  39  sets the value to the STATUS container using the following command: 
     SET (STATUS, error_condition, “none”, “data”). 
     In response to each such SET command, the STATUS container stores the value of the parameter and updates its dictionary with the parameter name (Step S 04 ). 
     Because a SET command will automatically overwrite existing name&#39;d information, it is in some circumstances prudent for the print server to test the container before issuing a SET to determine if information already exists in the container with the same name. In this situation, the print server, or any computer process desiring to test the container, first issues a GET command with the desired name. If the name already exists in the container, then a value will be returned and the print server can decide whether or not to proceed with the SET; otherwise the container will return an error code and the print server will know it is safe to proceed with the SET. Using this GET-before-SET sequence, any computer process can ensure that it will not accidentally overwrite needed information. 
     Such functionality may also be provided directly, for example, through an “ISVARIABLE” function which checks a container for the existence of a variable and returns TRUE if the variable name exists and FALSE otherwise. This functionality and other types of functionality can be provided by expanding the command set to which the container is responsive. 
     In Step S 05 , print server  39  creates additional containers to store more complex setup and control information. For example, in Step S 05 , print server  39  may store font information which includes the fonts that are available for printing by printer  21 , the default font which is automatically selected by printer  21  upon power up, and the currently selected font. While each one of these parameters may be stored individually in Step S 03 , it is also possible to create a new container which stores all such related information. Thus, in Step S 05 , for each container-type parameter, print server  39  sets the name of the new container to the STATUS container. For example, to create a FONT container, server  39  issues the following command: 
     SET (STATUS, “FONT”,, container). 
     In response to such a SET command, the STATUS container creates a new container named “FONT” which has all the functionalities of any container. The STATUS container updates its dictionary of names and includes the container-type qualifier with that dictionary. 
     In Step S 07 , print server  39  sets the name of sub-parameters and their values to the appropriate sub-containers. For example, to store font information, the print server  39  issues the following commands: 
     
       
         
               
               
             
               
             
           
               
                   
               
             
             
               
                 SET (FONT, AVAILABLE_FONTS, 
                 “COURIER_10 PT 
               
               
                   
                 COURIER_12 PT 
               
               
                   
                 UNIVERS_10 PT 
               
               
                   
                 UNIVERS_12 PT 
               
               
                   
                 ROMAN_10 PT 
               
               
                   
                 ROMAN_12 PT”, Data) 
               
             
          
           
               
                 SET (FONT, DEFAULT_FONT, “COURIER_12 PT”, Data) 
               
               
                 SET (FONT, CURRENT_FONT, “COURIER_12 PT”, Data) 
               
               
                   
               
             
          
         
       
     
     In response to each such SET command, the sub-containers execute container processing to store the value of the named information and to update the dictionary in the sub-containers with the appropriate names. 
     After the print driver has stored all setup and control parameters in the containers, flow advances to Step S 08  in which the print server  39  signals driver  31  that setup/control parameters are stored in the STATUS container. Signaling is performed over LAN bus  11  and, in response to the signal, print driver  31  queries the STATUS container to get the name of each parameter in the container and to store its value into designated buffers (Step S 09 ). If the names of all information are known to the driver  31 , then driver  31  simply issues a series of GET commands to the status container and to all the sub-containers. On the other hand, if the names are not known, then the driver  31  simply issues a GET_FIRST command followed by sequential GET_NEXT commands so as to sequence through the entire dictionary stored in the STATUS container. In response to the GET commands, the STATUS container will check against its dictionary and return the named values to driver  31 . If the named information returned by the status container is data-type information, then driver  31  simply stores the named information if the named information is of interest; otherwise the information is ignored. On the other hand, if the named information returned from the STATUS container is container-type information, then driver  31  issues a further GET command to the sub-container whereby all the information stored in the STATUS container is retrieved. 
     Flow advances to Step S 11  in which driver  31  displays a dialogue box of setup and control parameters to the user. A representative dialogue box is illustrated in FIG.  4 . As seen there, the dialogue box simply lists information names and associated information values. The dialogue box further preserves the hierarchy of the container/sub-container structure. More specifically, with respect to the “FONT” sub-container, the dialogue box indicates that a sub-container has been encountered by indenting the information names stored in that sub-container, thereby displaying the setup and control parameters in a hierarchical structure that is the same hierarchical structure that is defined by the print server  39  when it stored those parameters. Significantly, there is no need for a driver  31  to be aware of that hierarchy or indeed even to know the names of the parameters. Both the hierarchy and the names are part of the container and are SET there by the setting computer process. 
     In Step S 12 , the computer operator at work station  16  updates the parameters displayed at the work station. For example, the operator may decide to change the current font or to change the default font setting. The operator makes the changes that are desired, whereupon flow advances to Step S 13  in which driver  31  sets the name and value of each parameter that has been changed back to the STATUS container or the appropriate sub-containers. In Step S 14 , the STATUS container, referring to its dictionary, determines that the updated values are already part of the container and therefore does not allocate any additional storage space, but rather simply replaces the value currently stored therein with the new value. 
     Flow then advances to Step S 15  in which driver  31  signals server  39  over LAN bus  11  that setup and control parameter values have been changed. In response, in Step S 16 , server  39  queries the STATUS container and any sub-containers to GET values of all the named parameters. Note that in this embodiment it is necessary for server  39  to GET the values of all named parameters since driver  31  has not indicated which parameters have been changed. Other arrangements are possible. For example, driver  31  may create a new container named, for example, “CHANGES”, and SET to that container the names of all parameters that have been changed. By reference to the “CHANGES” container, the server  39  may determine which parameters have been changed and GET only the changed parameters. 
     In either event, in response to GET commands from server  39 , the STATUS container (or appropriate sub-containers) retrieves the named information from the container by reference to the container&#39;s dictionary and provides the requested values to server  39  (Step S 17 ). Flow then advances to Step S 18  in which server  39  destroys the STATUS container. In response, the STATUS container first destroys all its sub-containers (Step S 19 ) and then releases its memory. 
     In Step S 20 , driver  31  creates a “PRINT_JOB” container. The PRINT_JOB container may be contained in another container if desired; for example, rather than destroying the STATUS container it can be preserved and the PRINT_JOB container created as a sub-container to the STATUS container. In Step S 21  driver  31  sets print job parameters to that container. Print job parameters include not only print information, but may also include additional settings such as the font selected specifically for the print job or the current orientation (portrait or landscape) for printing. In Step S 22 , the PRINT_JOB container updates its dictionary with the names of the SET information, and stores the values of that information. Flow then advances to Step S 23  in which driver  31  signals server  39  via LAN bus  11  that a print job exists in container PRINT_JOB, or that the PRINT_JOB container has been placed in the job queue. In response, in Step S 24 , server  39  queries the print job container to GET print job parameter values. The PRINT_JOB container provides the print job parameters (Step S 25 ) and in Step S 26  the print server  39  executes the requested printing service on printer  21 . Flow advances to Step S 27  in which print server  39  destroys the PRINT_JOB container, in response to which, the PRINT_JOB container destroys its sub-containers and then releases its memory space (Step S 28 ).