CN102804137A - Controlling access to software component state - Google Patents

Abstract

A request is received from a software component of a software product to access a value of a public setting of the software component. A check is made as to whether the request conforms to an appropriate format for the public setting. If the request conforms to the appropriate format, then the requested access is performed. However, if the request does not conform to the appropriate format, then the requested access is denied. Multiple values for the public setting can be received and maintained concurrently.

Description

Control access to the state of software components

Background technique

Computers typically run an operating system that provides various functionality including allowing other applications to be installed and run on the computer. Such operating systems often provide a storage location where applications can store various types of information to be persisted across multiple executions of the application. This storage location may be, for example, an operating system register. While maintaining such information can be beneficial to applications, current storage mechanisms all suffer from their problems. One such problem is that different applications typically interact with the same storage unit, leading to situations where information stored by one application is deleted, overwritten, or otherwise corrupted by another application. Such a situation can cause the application not to function as planned, or even to fail to function at all.

Contents of the invention

This Summary is provided to introduce a selection of concepts in a simplified form that are also described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

According to one or more aspects, a request is received from a software component of a software product to access a value of a setting of the software component. Such settings are, for example, configuration information that a software component intends to store in such a way that the configuration information persists beyond the runtime of the software so that subsequent activations of the software can read the persistent information and rebuild that configuration. Checks that the request conforms to the appropriate format for this setting. If the request conforms to the appropriate format, the requested access is performed. However, if the request does not conform to the proper format, the requested access is denied.

According to one or more aspects, a setup declaration for a software component is received. A setting declaration identifies the appropriate format for accessing the declared setting. Records of setting statements are kept. Multiple values for the stated settings are also received, and the multiple values are preserved at the same time.

Description of drawings

The same reference numbers are used throughout the drawings to refer to the same features.

Figure 1 illustrates an example computing device that enables controlled access to software component state, in accordance with one or more embodiments.

Figure 2 illustrates exemplary software components in accordance with one or more embodiments.

Figure 3 illustrates an example computing device that enables controlled access to software component setting values, in accordance with one or more embodiments.

Figure 4 is a block diagram illustrating an exemplary file system hierarchy for storing software component states in accordance with one or more embodiments.

Figure 5 is a flow diagram illustrating an exemplary process for a device controlling access to software component settings, in accordance with one or more embodiments.

Figure 6 is a flow diagram illustrating another exemplary process for a device controlling access to software component settings, in accordance with one or more embodiments.

Figure 7 illustrates an example computing device that may be configured to enable controlled access to software component state, in accordance with one or more embodiments.

Detailed ways

Controlling access to software artifact persistence settings is discussed here. These settings persist across different executions of the software component. The software product consists of one or more software components, each of which can communicate with the settings storage control module. The settings storage control module controls access to at least some persistent state associated with software components. A software component may store a type of persistent settings (referred to as public settings) to which access is controlled by a settings storage control module. Software components can also store other types of persistent settings or information (known as private state). In the case of both public settings and private state, the location where persistent state data for software components is stored is controlled. In the case of public settings, the structure and type of data are constrained by the storage control module in accordance with each constraint imposed by the declared setting schema of the software component. In the case of private state, the software component itself determines the structure and type of data, but not where that data is actually stored.

Specific public settings that can be accessed by a particular software component are declared in a settings schema as part of the software component's immutable manifest. The settings storage control module constrains each software component to only access public settings of software components declared in the settings mode; other requests from software components to access public settings are denied by the settings storage control module.

Additionally, the settings storage control module may retain and allow access to multiple different values for each setting. When a setting value is written, the location where the setting value is stored may be dependent on the identity of the writer of the value. Thus, different components, modules, devices, etc. can have different setting values stored and persisted for the same setting at the same time. An algorithm or set of rules may be used to identify which of those different setting values is to be returned in response to a request for a value for a particular setting.

FIG. 1 illustrates an example computing device 100 that enables controlled access to the state of software components, in accordance with one or more embodiments. Computing device 100 may be a wide variety of different devices capable of running applications. For example, computing device 100 may be a desktop computer, server computer, laptop computer, mobile station, entertainment appliance, set-top box communicatively coupled to a display device, cellular or other wireless telephone, game console, automotive computer, and the like. Thus, computing device 100 may range from a full-resource device (e.g., personal computer, game console) with substantial memory and processor resources to a low-resource device with limited memory and/or processing resources (e.g., a traditional set-top boxes, handheld gaming consoles).

Computing device 100 includes software component settings store control module 102 and software component state store 104 . Two software products 106 and 108 —also referred to as software applications—are illustrated as included in computing device 100 . Although two software products 106 and 108 are illustrated in the example of FIG. 1 , alternatively, fewer than two or more than two software products may be included in computing device 100 . Each software product 106 and 108 includes one or more software components. In the example of FIG. 1 , software product 106 includes software component 112 , software component 114 , and software component 116 , while software product 108 includes software component 116 and software component 118 . As can be seen on FIG. 1 , multiple different software products may share software components (eg, software component 116 ).

The component software settings storage control module 102 manages the storage of and access to at least some of the settings for the software components 112 - 118 in the software component state repository 104 . These settings are configuration information for the software components 112-118 that are persisted by the control module 102 across different executions of the software components 112-118. A number of different settings may be managed by the control module 102 for each software component 112-118. Each of these various settings has a setting identification and one or more setting values, as discussed in more detail below. The particular settings stored by software components 112-118 and how those settings are used by software components 112-118 are determined by the developer of each software component 112-118. However, storage of the value or values of the settings is controlled and managed by the control module 102 .

As can be seen in Figure 1, each software product consists of one or more software components. The software components of a software product include instructions and data executable on computing device 100 and together provide the functionality of the software product. Access to the control module 102 is made by software components at runtime, not by the software product as a whole.

Figure 2 illustrates an exemplary software component 200 in accordance with one or more embodiments. A software component is a collection of one or more files and metadata describing the software component. The software component 200 includes one or more resource files 202 each storing various instructions and/or data for the software component 200 . The particular resource files 202 included in the software component 200 may vary according to the wishes of the developer of the software component 200.

Inventory 204 stores metadata describing software component 200 . In one or more embodiments, inventory 204 includes an identifier for software component 200, one or more version numbers for software component 200, and one or more public settings declarations for software component 200 (collectively referred to as for "setup mode"). The identifier of the software component 200 allows the software component 200 to be distinguished from other software components installed on the device. The identifier may be generated in a variety of different ways, such as from a name given by the developer of the software component 200, an identifier of the developer of the software component 200, an identifier of the publisher or issuer of the software component 200 , the version number of the software component 200, and so on.

The version number of the software component 200 enables different versions of the software component 200 to be easily identified. In one or more embodiments, two different version numbers are included in inventory 204: a contract version number and a service version number. Alternatively, the contract version number and the service version number can be combined together into a multi-element number, with one or more elements being the contract version number and one or more elements being the service version number. These version numbers may be used to facilitate upgrades of the software component 200, while preserving previous state settings in some cases, as discussed in more detail below.

The public settings schema declared in the inventory manifest 204 specifies the name, data type, and default value for each of the one or more public settings leveraged by the software component. Each public setting declaration in the schema is utilized by the storage control manager to ensure that a software component's runtime access to that particular setting is in the correct format (verification of the correct format is the responsibility of the storage control module 102 of Figure 1 one). Different implementations of values associated with each declared common setting (e.g., default values, software values written by software components, and policy override values discussed in more detail below) across software components 200 And keep. For example, execution of software component 200 may be terminated and subsequently restarted, and when restarted, stored values for settings of software component 200 may be retrieved such that software component 200 has the The same setting for the same setting value.

Specific settings declared in settings mode are declared with one of several operating system-defined low-level data types, such as Integer, String, Boolean, and so on. Multiple settings can be declared in a settings schema to represent more complex data types as composites of this set of primitive data types. For example, common settings can be declared to represent things such as screen position (e.g., identifying where a portion of the user interface is to be displayed), font size and/or font, language preference, default location, volume level preference, enabled Or disable specific input devices and so on.

It should be noted that settings whose values are stored by software component 200 refer to software state, not user data. Software state refers to data that has a location and lifetime managed by the operating system (or, alternatively, by another application), although the value of software state may be changed in response to user requests. User data, on the other hand, refers to data files (eg, specific document files, picture files, music files, etc.) that have a location and lifetime that are clearly managed by the user.

Software component 200 may store public settings and/or private states. Private state refers to unschematized information whose structure and data type are determined by the software component's implementation scheme (ie, private state is not schematized in a setting declaration). Private state and its storage are discussed in more detail below.

Public settings, on the other hand, refer to states managed by a software component settings storage control module, such as module 102 of FIG. 1 . Inventory 204 includes, for each public setting, a setting declaration, identifying the setting identity, the type of information stored for that setting, and optionally a default value for that setting.

In one or more embodiments, a public settings declaration in inventory 204 includes three elements: name, type, and default. The name specifies a name (moniker) that identifies the common setting, distinguishing it from other common settings used by the software component 200 . Types identify data types for common settings (eg, the size, format, and semantics used to store specific values). A wide variety of different setting types can be supported, such as integers, booleans, strings, date and/or time values, references to files or directories, and so on. Default values identify default values for common settings as specified by the developer of software component 200 . This default value is retained, although the value of this setting may thereafter be changed, as discussed in more detail below. In one or more embodiments, each setting has a default value, although default values such as empty strings, "null" or zero values may be used. In other embodiments, the developer may not provide a default value.

Returning to FIG. 1, each software component 112-118 may retain private state and/or public settings. Each software component 112 - 118 may store any data or information it wants, and is not constrained to pre-declare its private state to the control module 102 . However, the location of private state data is controlled by the operating system. Storage control module 102, or alternatively, another component or module of the operating system of computing device 100, provides each software component with one or more locations in the file system hierarchy or in other registry repositories, in where it can store its private state.

On the other hand, public settings refer to settings managed by the storage control module 102 . Each software component 112-118 pre-declares the specific settings it wishes for the module 102 to retain as common settings. This pre-declaration is done, for example, by using the common settings declaration of the inventory as discussed above. Public settings declarations are pre-declared to module 102 before running software components attempt to access public settings.

The pre-declaration of public settings provides the control module 102 with the exact specification for those settings in the appropriate format. By pre-declaring its public settings, a software component is constrained to only access the pre-declared public settings. For example, a state is constrained by the control module 102 to have a name as pre-declared, to have a setting type as pre-declared, and to have a default value as pre-declared.

FIG. 3 illustrates an example computing device 300 that enables controlled access to software component settings, in accordance with one or more embodiments. Computing device 300 may be, for example, computing device 100 of FIG. 1 . For ease of illustration, a software product 302 with a single software component 304 is illustrated on FIG. 3 . It should be appreciated, however, that multiple software components may be included in a software product as discussed above.

Software component 304 may store public settings and/or private state in software component state repository 306 . Software component state repository 306 may be, for example, repository 104 of FIG. 1 . Private state portion 308 of repository 306 stores arbitrary information at the discretion of the software component developer in a location determined by the operating system of computing device 300, while public settings portion 310 of repository 306 stores public setting values. The software component 304 can directly access the private state portion 308, saving, retrieving and otherwise accessing the private state as desired in a location dictated by the operating system of the computing device 300. The software component 304 can be informed of this location by the operating system, or alternatively, the location can be abstracted by the operating system, and the software component can access the private state portion via one or more Application Programming Interface (API) methods exposed by the operating system 308.

However, software component 304 accesses public settings portion 310 via software component settings storage control module 312 . Control module 312 is typically implemented as part of an operating system running on computing device 300, although control module 312 may alternatively be implemented as a separate module or component. Thus, requests from software component 304 to save, retrieve, or otherwise access public settings portion 310 are performed by module 312 rather than directly by software component 304 to repository 306 . The control module 312 may be, for example, the control module 102 of FIG. 1 .

The name of a public setting used by software component 304 identifies the public setting to storage control module 312 and allows module 312 to distinguish the public setting from other public settings used by software component 304 . Module 312 utilizes the settings mode to verify named public settings, as discussed above. This name of the public setting used by the software component 304 may be the name of the setting as declared in the settings schema, or alternatively may be another name associated with the name of the setting as declared in the settings schema and/or more complex names to accommodate more complex type systems for common settings.

Private state portion 308 may also optionally include a discardable state portion 314 . Discardable state section 314 stores private state that is considered to be of low value and can be discarded while maintaining correct functioning of software component 304 . In one or more embodiments, discardable state section 314 stores private state that can be readily reassigned after being deleted from repository 306 . For example, software component 304 may use discardable state portion 314 as a type of performance cache for storing information computed by software component 304 or obtained from some other software component (eg, intermediate results of a very long computation). The performance of the software component 304 can be improved by retrieving the information from the discardable state portion 314 rather than recalculating or re-obtaining the information every time the software component 304 wants to use the information. However, if the discardable state portion 314 were to be deleted, this information could still be recomputed or retrieved to maintain correct functioning of the software component 304 .

Having a discardable state section 314 can be beneficial for a variety of different use cases. For example, a number of different reset levels may be employed, one of which may be deletion of private state in discardable state section 314, as discussed in more detail below. As another example, information in the discardable state portion 314 can be deleted when it is desired to reclaim storage space, and the discardable state portion 314 can be reclaimed for other uses.

Software component settings store control module 312 or another component or module of the operating system of computing device 300 controls software component state store 306 . This control includes the location of the repository 306 (e.g., a specific storage device or devices, a specific file system path, etc.) and the way the repository 306 is organized (e.g., using a file system hierarchy, tables, lists, etc. ).

Software component state repository 306 can be implemented in a variety of different ways. For example, repository 306 may be organized using a file system hierarchy (e.g., as discussed in more detail below with reference to FIG. 4 ), using one or more tables, one or more databases, one or more lists, other records, etc. waiting to be realized.

In one or more embodiments, software component state repository 306 is implemented in a file system hierarchy, such that different folders are used for different users of computing device 300 and different software components 304 . Some portions of the file system hierarchy may be associated with private status portion 308 , while other portions of the file system hierarchy may be associated with public settings portion 310 .

Figure 4 is a block diagram illustrating an exemplary file system hierarchy for storing software component settings in accordance with one or more embodiments. FIG. 4 illustrates a software component state repository 400 , which may be, for example, repository 306 of FIG. 3 and repository 104 of FIG. 1 .

As shown in FIG. 4 , repository 400 is organized with a highest or first level 404 , a second level 406 , a third level 408 , and a fourth level 410 . The first level 404 stores directories or folders for users. The particular software components available to different users on a computing device may vary, and the same software components used by different users may have different public settings and/or private states. In the example of FIG. 4, there is a single user (User A), although alternatively the highest level 404 may include additional directories or folders for each additional user on the computing device.

A second level 406 stores directories or folders for software components. Settings for different software components are stored in different locations. Each software component has its own subdirectory or subfolder under the folder in the highest level 404 . In the example of FIG. 4, there are two software components, although alternatively second level 406 may include additional directories or folders for additional software components, or alternatively include directories or folders for individual software components. folder.

A third level 408 stores directories or folders for public settings and private status. Each software component may have public settings and private state, and separate directories or folders are included in the third level 408 to store the public settings and private state. A public subdirectory or subfolder and a private subdirectory or subfolder are included under each software component directory or folder in the third level 406 . One or more files storing common settings for a software component may be included in a public subfolder under the folder for the software component. A separate file may be included in the common subfolder for each common setting, or alternatively, multiple common settings may be included in a certain file in the common subfolder.

A fourth level 410 stores directories or folders for disposable private state. Private state may include discardable state, as discussed above. Information for discardable private states is stored as one or more files in a discardable subfolder in the fourth level 410, while information for other private states is stored as one or more files in a third level 410. Private subfolders in level 408.

Returning to FIG. 3 , software component settings storage control module 312 obtains one or more public settings declarations 320 . Each public setting declaration 320 is a pre-declared setting for software component 304 as discussed above. In one or more embodiments, public settings statement 320 is provided to control module 312 by an installation component or module when software component 304 is installed on computing device 300 . Alternatively, the control module 312 may obtain the public settings statement 320 in a different manner. For example, public settings statement 320 may be retrieved by control module 312 from a remote service (e.g., via the Internet or another network), from another local repository on computing device 300 (removable or fixed computer storage media), from another A remote service or source, retrieved from another computing device, etc.

Once obtained, the control module 312 enforces compliance with the public settings statement 320 . During execution, the control module 312 receives a request from the software component 304 to access the public settings of the public settings section 310 . The control module 312 checks the accesses to verify that they match the public settings statement 320 . For example, the control module 312 verifies that the setting identity and type of access match the setting identity and type declared in the public setting statement 320 .

Control module 312 also exposes an application programming interface (API) 326 that allows software component 304 to request access to public settings of software component 304 . Various accesses are granted, such as writing software values for common settings, reading valid values for common settings, enumerating common setting modes, removing previously written software values for common The values revert back to the default values used for the software component 304, and so on.

To request that a software value be written for a public setting, software component 304 provides the setting's name and desired value. By writing software values for common settings, software components 304 are able to override default values set by developers as part of the pre-declaration of the settings.

In response to a request to write a software value for a public setting, the control module 312 verifies that the request conforms to the setting's pre-declared format. This verification includes verifying that the name of the setting included in the request has been pre-declared, and verifying that the desired value type is the same as the value type that has been pre-declared for the setting. If the request conforms to the pre-declared format of the setting, the request is executed by storing the provided value in the public settings section 310 for the provided name. However, if the request does not conform to the pre-declared format of the setting, the request is rejected.

For example, assume that software component 304 requests that a particular value be written as the value for a particular setting. If the name of the particular setting is not the name of a setting that has been pre-declared for the software component 304, the control module 312 denies the request. If the name of the particular setting matches (is the same as) the name of a pre-declared setting for the software component 304, but the setting type is different (for example, the setting type for the specified setting is pre-declared as boolean, but trying to The written value is a string value), then the control module 312 rejects the request. However, if the name of the particular setting matches (is identical to) the name of a setting that has been predeclared for software component 304, and the setting type matches (is identical to) the setting type that has been predeclared for that predeclared setting name , the control module 312 executes the request.

In response to a request to set a readout value, the control module 312 verifies that the request conforms to the set's pre-declared format. This verification includes verifying that the names of the settings included in the request have been pre-declared. If the request conforms to the pre-declared format for the setting, the request is executed by retrieving from the common settings section 310 the value for the setting specified in the request. When multiple values are stored for the settings specified in the request, the particular value of the multiple values retrieved may be determined according to various algorithms or rules as discussed in more detail below. However, if the request does not conform to the pre-declared format of the setting, the request is rejected.

It should be appreciated that because control module 312 manages access to common settings section 310, control module 312 can prevent software component 304 from writing an incorrect value type for a setting and inadvertently overwriting a value for another setting. Software components 304 do not directly access public settings section 310 . Instead, the control module 312 accesses the common settings section 310 in response to a request from the software component 304 and writes values to the appropriate locations in the common settings section 310 . It should also be noted that this control via module 312 prevents software component 304 from inadvertently overwriting the value of a setting for another software component. For example, common setting values for different software components are by definition maintained in different repositories (an exemplary embodiment of which is described above with reference to FIG. 4 ). Because the repositories are maintained separately, different software components need not worry that modifying software values for their declared settings will modify software values associated with any other component. Additionally, as discussed above, the control module 312 may store common settings for different users in different sections of the common settings section 310 . The current user of computing device 300 may be determined in a variety of different ways, such as communicating with another component or module to identify a particular user currently logged into computing device 300, identifying a user currently assigned to use computing device 300 specific user of the processor, and so on. Thus, different public settings are stored for different users, even though different users may be using the same software component.

Additionally, running software component 304 results in what is typically referred to as an instance of software component 304 being created. In one or more embodiments, multiple different instances of software component 304 may be running concurrently for the same current user. For example, a request to run the same software component 304 may be received many times concurrently from a user and/or another component or module. In such a case, the multiple different instances share the same portion of common settings section 310 . Thus, a setting value written to common settings portion 310 by one instance of software component 304 (via control module 312 ) may subsequently be read by another instance of software component 304 (via control module 312 ). Likewise, the multiple different instances also share the same portion of the private state portion 306 .

For example, assume that software component 304 provides scratchpad functionality, allowing users to create and save text notes. Different instances of software component 304 share the same common settings, allowing setting changes (such as desired language, font size, change of font, etc.) to be the same for multiple instances of software component 304 .

It should be noted that, as discussed herein, the control module 312 manages access to common settings on a software component basis. It is not the software product that requests access to the common settings, but the individual software components that make up the software product request access to the common settings. Accordingly, it should be appreciated that changes to common settings made by a software component when executing as part of one software product may subsequently be retrieved by that software component when executing as part of another software product.

In one or more embodiments, the software component setting storage control module 312 maintains multiple different values for the same setting. These different values may be provided by different entities, such as a developer (who provides default values), software component 304, an administrator of computing device 300, an administrator of a network to which computing device 300 is coupled, and so on. These different values are provided to override certain other values, such as administrator override values that override default values from developers; administrator override values that override values set by software component 304; Administrator override values may also be referred to as policy override values. These different values may be maintained in different ways, such as in different parts of the common settings section 310 . For example, a public folder (eg, at level 408 of FIG. 4 ) may have multiple subfolders, each subfolder corresponding to a different entity. As another example, values from software components 304 may be maintained in public folders (e.g., in level 408 of FIG. 4 ), while values from other entities may be maintained in other folders, tables, lists, etc. middle. Control module 312 or another component or module may impose access rights on such folders, tables, lists, etc., allowing control module 312 to access such folders, tables, lists, etc., but preventing software component 304 from accessing such folders , tables, lists, etc.

These different entities can provide their respective values for the settings in a variety of different ways. Default values from the developer may be provided in the public settings declaration 320 as discussed above. Values from software components 304 may be included in write requests via API 326. Values from the administrator may be included in the write request via the API 326, may be provided to the control module 312 via another interface, may be stored in the repository 306 (or another repository) in a known location (known to both the administrator and the control module 312).

In one or more embodiments, the entity of writing or otherwise storing a value is inherently given by the manner in which the writing or storing occurs. For example, values in public settings declaration 320 are default values from developers, values received via API 326 are values from software components 304, and so on. Alternatively, the entity writing or otherwise storing the value may be otherwise identified. For example, an entity may provide its own identifier prior to making a write request, an entity may provide its own identifier as part of a write request, and so on.

When software component 304 requests that a value be read for a setting, software component 304 may identify which of a plurality of values it is requesting for the setting. For example, software component 304 may identify that it is requesting default values, values set by software component 304, and the like. In one or more embodiments, software component 304 identifies which of the multiple values it is requesting for the setting by including an identifier of which of the multiple values it is requesting in the request. Alternatively, software component 304 may identify which of the multiple values it is requesting for the setting in other ways, such as by calling different methods of API 326 for different values (e.g., a readout default value method, another method to read the value previously set by the software component 304, etc.).

In one or more embodiments, software component 304 may identify that it requests to read an "effective value" for a setting. In response to such a request, the control module 312 determines a valid value for the setting (assuming the read request is verified to be in the pre-declared format for the setting) and returns the valid value to the software component 304 . A valid value is one of the values stored for the setting, a particular valid value being determined according to a specific algorithm or set of rules. This algorithm or set of rules describes which of a plurality of values has priority over other values of the plurality and is therefore the value to be returned in response to a request to set a value.

In one or more embodiments, the control module 312 determines the effective value according to the following rules. If there is a value set by the administrator for this setting, then that value is valid. Otherwise, if there is a value set by software component 304 for the setting, then that value is a valid value. Otherwise, the default is a valid value.

In one or more other embodiments, the control module 312 determines the effective value according to the following rules. If there is an administrator override value to override the value set by software component 304, then the value is a valid value. Otherwise, if there is a value set by software component 304 for the setting, then that value is a valid value. Otherwise, if there is an administrator override value to override the default set of values, then that value is valid. Otherwise, the default is a valid value.

Additionally, in one or more embodiments, common settings may be grouped together to form atomic units. When a plurality of common settings are grouped together, the control module 312 writes the grouped settings into the common setting part 310 as a group. While software component 304 (or a different instance of it) may have access to read and/or write individual public settings of these aggregated public settings if desired, module 312 ensures that they are written as a group Go to Section 310.

For example, four values can be used to identify the position of the rectangle to be displayed (eg, upper left value in the "x" dimension, upper left value in the "y" dimension, right lower right value and lower right value in the "y" dimension). Each of the four values can be a different common setting, and the four common settings can be declared as being grouped together. Thus, if control module 312 receives a request from software component 304 to write one or more of these four values, control module 312 writes all four values to portion 310 . The control module 312 thus prevents a situation where an instance of a software component writes one of the four values stored in the public settings section 310 - a situation which in this example could result in the stored coordinates being meaningless.

Additionally, in one or more embodiments, API 326 exposes one or more methods that allow software component 304 to access its own public settings. Different methods can be exposed to allow different types of access (eg, read access, write access, enumeration access, etc.). Table I below describes examples of such methods that may be called by software component 304 .

Table I

method illustrate read set value Allows a software component to read the value of a specified setting. The caller specifies the setting name (eg, path) and the desired value type (eg, default, valid, etc.) as parameters. write setting value Allows a software component to write the value of a specified setting. The caller specifies the setting name (eg, path) and the desired value type (eg, default, valid, etc.) as parameters. Reset setting value Allows a software component to remove any public setting values previously written by the component. The caller specifies as an argument the setting name (eg, path) for which to remove the setting value. enum setting value Allows a software component to enumerate settings for a specific setting name (eg, path). The caller specifies a setting name (eg, path) or an empty string as an argument to indicate all public settings of the software component. Information about each setting (or all public settings for this software component) for the specified setting name is returned. get status directory Returns the location of the private state part (for example, a folder path name). The caller specifies the type of state directory (eg, discardable or non-discardable). If no folder already exists in the software artifact state repository, the folder is created before the location is returned to the caller. Reset state Resets this setting and optionally other states for the specified software component. The caller can specify which settings or other state to reset (eg, only discardable state, all state, etc.), as discussed in more detail below.

FIG. 5 is a flow diagram illustrating an example process 500 for a device controlling access to software component settings, in accordance with one or more embodiments. Process 500 is carried out by a device, such as computing device 100 of FIG. 1 or computing device 300 of FIG. 3 , and it may be implemented in software, firmware, hardware, or a combination thereof. Process 500 is an example process for controlling access to software component settings; additional discussions of controlling access to software component settings are included herein with reference to different figures.

In process 500, one or more setup statements for a software component are received (act 502). Each setting declaration indicates the appropriate format for accessing the declared setting. The setting statement can be received in a variety of different ways as discussed above.

An immutable record of the setting declaration is kept (act 504). Keeping this record allows, for example, to subsequently verify that access to declared settings conforms to the proper format. This reservation may be, for example, storing the inventory received at act 502 and/or storing settings including default values derived from the inventory received at act 502 . Execution of the software component implementation cannot modify the setup schema, since this information is an immutable part of the software component's published inventory contract.

For each declared setting of the one or more declared settings, a plurality of values are received (act 506 ). The plurality of values may include values from a variety of different entities, etc., as discussed above.

Each value of the received plurality of values is retained simultaneously (act 508). Because each of the plurality of values is stored, different ones of the plurality of values may be returned in response to different requests as discussed above.

FIG. 6 is a flowchart illustrating an example process 600 for a device controlling access to software component settings in accordance with one or more embodiments. Process 600 is carried out by a device, such as computing device 100 of FIG. 1 or computing device 300 of FIG. 3, and may be implemented in software, firmware, hardware, or a combination thereof. Process 600 is an exemplary process for controlling access to software component settings; additional discussions of controlling access to software component settings are included herein with reference to different figures.

In process 600, a request to access a value of a setting is received from a software component (act 602). This request may, for example, be received via an API exposed by the software component settings storage control module as discussed above.

The request is compared to the declared format for the setting (act 604), and a check is made as to whether the request conforms to the appropriate format for the setting (act 606). This check may include various operations, such as checking the setting name, setting type, whether atomicity is maintained, etc. as discussed above.

If the request conforms to the appropriate format for the setting, then the requested access is performed (act 608). However, if the request does not conform to the proper format for the setting, then the requested access is denied (act 610) and thus not performed.

The techniques for controlling access to software component state discussed herein provide control over the common settings of software components, help prevent inadvertent overwriting of setting values, and provide a more consistent setting model for developers to utilize. Additionally, the techniques discussed here for controlling access to software component state provide for a variety of use cases.

In one or more embodiments, controlling access to the state of the software component allows multiple reset levels for the software component. Different reset levels may be utilized, each of which changes private states and/or public settings for software components. For example, a reset level may delete all state in the discardable state section of the private state section, but leave the rest of the private state section and the public settings section unchanged. After such a reset, the values of the software component that are kept in the private state section (except for the discardable state section) and the public settings section are still accessible to the software component. As another example, another reset level may delete all state in the private state section (regardless of whether the information is in the discardable state section), but leave the public settings section unchanged. After such a reset, the settings of the software component that were retained in the common settings section are still accessible to the software component. As yet another example, yet another reset level may delete all values set by the software component, effectively returning the settings of the software component to their default levels (the default values provided in the public settings declaration). After such a reset, the software component's default values are still accessible to the software component.

Additionally, controlling access to software component state allows software components to be upgraded to new versions while preserving previous private state and public setting values. As discussed above, version numbers may include contract version numbers and service version numbers. In one or more embodiments, the software component setting storage control module identifies software components with the same contract version number as the same software component even if the service version numbers are different. However, the software component setting storage control module recognizes software components having different contract version numbers as different software components. Thus, a developer can release a new version of a software component with the same contract version number, but a new service version number, and still have the software component access private state and public setting values stored by previous versions of the software component.

Furthermore, in one or more embodiments, controlling access to software component state facilitates migration of software components. Such migration may refer to transferring a software component from one computing device to another, or changing the operating system used by the computing device on which the software component is installed. Regardless of the type of migration, public settings and private state values for software components are preserved in specific sections of the software component settings repository. These specific parts are known, and this knowledge can be exploited during migration to allow public settings and private state values to be migrated along with the software components (to a different computing device and/or a different operating system).

FIG. 7 illustrates an example computing device 700 that may be configured to enable controlled access to software component states, in accordance with one or more embodiments. Computing device 700 may be, for example, computing device 100 of FIG. 1 or computing device 300 of FIG. 3 .

Computing device 700 includes one or more processors or processing units 702, one or more computer-readable media 704, which may include one or more memory and/or storage components 706, one or more input/output (I/O ) device 708 and a bus 710 that allows various components and devices to communicate with each other. Computer-readable medium 704 and/or one or more I/O devices 708 may be included as part of computing device 700 or, alternatively, may be coupled to computing device 700 . Bus 710 represents one or more of several types of bus structures, including a memory bus or memory controller using a variety of different bus structures, a peripheral bus, an accelerated graphics port, a processor or local bus, etc. . Bus 710 may include a wired and/or wireless bus.

Memory/storage component 706 represents one or more computer storage media. Component 706 may include volatile media (such as random access memory (RAM)) and/or non-volatile media (such as read only memory (ROM), flash memory, optical disks, magnetic disks, etc.). Component 706 may include fixed media (eg, RAM, ROM, fixed hard drives, etc.) as well as removable media (eg, flash drives, removable hard drives, optical disks, etc.).

The techniques discussed here may be implemented in software with instructions executed by one or more processing units 702 . It should be appreciated that different instructions may be stored in different components of computing device 700, such as in processing unit 702, in various cache memories of processing unit 702, in other cache memories (not shown) of device 700, other computer-readable media, among others. Additionally, it should be appreciated that the location where instructions are stored in computing device 700 may change over time.

One or more input/output devices 708 allow a user to enter commands and information into computing device 700 and also allow information to be presented to the user and/or to other components or devices. Examples of input devices include keyboards, cursor control devices (eg, mice), microphones, scanners, and the like. Examples of output devices include display devices (eg, monitors or projectors), speakers, printers, network cards, and so forth.

Various techniques may be described herein in the general context of software or program modules. Generally, software includes routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. An implementation of these modules and techniques may be stored on or transmitted across some form of computer-readable media. Computer readable media can be any available medium or media that can be accessed by a computing device. By way of example, and not limitation, computer-readable media may include "computer storage media" and "communication media."

"Computer storage media" includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. deleted media. Computer storage media including, but not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage devices, cassette tapes, magnetic tape, magnetic disk storage devices or other A magnetic storage device, or any other medium that can be used to store desired information and that can be accessed by a computer.

"Communication media" typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism. Communication media also includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.

In general, any of the functions or techniques described herein can be implemented using software, firmware, hardware (eg, fixed logic circuits), manual processing, or a combination of these implementations. As used herein, the terms "module" and "component" generally represent software, although they may alternatively incorporate firmware and/or hardware. In the case of a software implementation, the modules or components represent program code that performs specified tasks when executed on a processor (eg, one or more CPUs). The program code may be stored in one or more computer readable memory devices, further description of which may be found with reference to FIG. 7 . The characteristics of the techniques for controlling access to software component state described herein are platform independent, meaning that the techniques can be implemented on a wide variety of commercial computing platforms with a wide variety of processors.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (15)

1. A computing device (700) comprising: a processor (702); and One or more computer-readable media (704) having stored thereon a plurality of instructions that, when executed by the processor, cause the processor to: receiving (602) a request from a software component of the software product to access a value of a public setting of the software component; Check (606) whether said request conforms to the appropriate format for the public setting; and If the request conforms to the appropriate format, the requested access is performed (608), otherwise the requested access is denied (610). 2. A computing device as claimed in claim 1, wherein the request to access the value is a request to write the value of the public settings to the public settings section of the repository. 3. A computing device as claimed in claim 1, wherein the request to access the value is a request to read out the value of the public setting from a public settings section of the repository. 4. A computing device as claimed in claim 1 , the instructions further causing the processor to receive the appropriate format as a common setting for storing an inventory of metadata describing the software component when the software component is installed on the device statement. 5. The computing device as recited in claim 1 , the instructions further causing the processor to reserve a plurality of values for the common setting, and wherein performing the requested access is determining a plurality of values for the common setting Which value in is to be returned to the software component. 6. A computing device as claimed in claim 5, wherein the request is a request for a valid value of a public setting, and wherein performing the requested access will: determining which of the plurality of values is a valid value based on one or more rules; and The value of the plurality of values determined to be a valid value is returned to the software component. 7. The computing device as recited in claim 6, wherein the one or more rules describe which of the plurality of values has priority, and the one or more rules include: a first rule indicating that if the plurality of values includes a first value set by an administrator, the first value is a valid value; a second rule indicating that: if the plurality of values does not include the first value, but includes a second value set by the software component, then the second value is a valid value; and A third rule indicating that a default value is a valid value if the plurality of values does not include the first value or the second value. 8. The computing device as recited in claim 1 , the instructions further causing the processor to: Multiple values reserved for this common setting; receiving a request to perform a reset of the software component; and In response to a request to perform a reset, one or more of the plurality of values is deleted while at least one of the plurality of values is retained. 9. The computing device as recited in claim 1 , the instructions further causing the processor to expose an application programming interface having a plurality of methods callable by the software component to request a plurality of different types of access, and Wherein receiving the request will cause one of the plurality of methods to be invoked by the software component. 10. The computing device as recited in claim 1, the instructions further causing the processor to allow the software component to access the private state of the software component without checking that the access conforms to an appropriate format for the private state. 11. A method implemented by one or more processors of a device, the method comprising: receiving (502) a setting declaration for the software component, the setting declaration identifying an appropriate format for accessing the declared setting; For the declared setting, receive (506) multiple values; and The multiple values are retained (508) at the same time. 12. The method as recited in claim 11, wherein receiving the setup declaration comprises receiving the setup declaration as part of an inventory storing metadata describing the software component. 13. A method as claimed in claim 12, wherein the setting statement includes one of a plurality of values. 14. The method as recited in claim 11, further comprising: receiving a request from a software component for a valid value for a declared setting; determining which of the plurality of values is a valid value based on one or more rules; and The value of the plurality of values determined to be a valid value is returned to the software component. 15. The method as recited in claim 14, wherein the one or more rules include a rule indicating: if the plurality of values includes a first value that is an administrator override for a value set by the software component, the first value is a valid value; Otherwise, if the plurality of values includes a value set by a software component, the value set by the software component is a valid value; Otherwise, if the plurality of values includes a second value as an administrator override for the default value, then the second value is the valid value; and Otherwise, the default is a valid value.

Images