The final basic component of our API is named 'properties'. Its main purpose is allowing to store end-user software's customization data on the cloud, to avoid the common situation found in most apps, that store customization data on the user's device: if he logs into another device (because his run out of battery, for example), customization data will not be available. Also, it seems useful to us that customization data can be shared across a set of solutions owned by a single developer team or corporation: for example, if a bank allows their customers to access their account from the web and from their smartphones, it will be useful to end-users to share their options for which banking operations to have shortcuts on the initial screen of both banking channels – having to customize them separately results in a poorer user experience.
That is why the 'Property…' APIs are part of the basic API components of our cloud-based time-limited transaction manager. Properties are defined on a per-solution basis (which does not prohibit from sharing data among solutions: if the developers are one single team, or different teams outsourced by a single corporation, they just need to share solution tokens).
As the total number of properties could be huge, properties are designed as a hierarchical system, which starts with a solution, and classifies properties into groups and categories: each solution encompasses various property categories, each category encompasses various property groups, and each property group contains a number of properties. This hierarchy is structurally similar to the storage of customization data based on '.ini' files or hierarchical databases (like the Windows registry).
For each of this three hierarchical levels (categories, groups and properties) we have three similar APIs, which allow to validate the category, group or property name (respectively, the 'PropertyCategoryValid', 'PropertyGroupValid' and 'PropertyValid' API calls), as well as three transactions to add new names at each level (represented by the six API calls 'PropertyCategoryAddAllow', 'PropertyCategoryAddCommit', 'PropertyGroupAddAllow', 'PropertyGroupAddCommit', 'PropertyAddAllow' and 'PropertyAddCommit').
Besides storing data inside our cloud-based time-limited transaction manager's finite state automaton so that it can be accessed at any time, from any device, our customization storage improves on traditional mechanisms in two additional aspects.
The first improvement is based upon our type system: when adding a property to the hierarchy, developers have to define the type of the values to be used. Each property's type can be retrieved later on by means of 'PropertyTypeGet' API calls.
The second improvement consists in properties having a number of different 'instances', based on two variations. The first variation to instantiate property values is based on the 'PropertyValueSetAllow' API's parameter named 'LanguageCode' (of type 'language'), allowing each property to have as many values as there are human languages defined on our cloud-based time-limited transaction manager (so that we effectively support multilingual end-user software).
Each language-based instance of a property should be the translation of the same piece of data into the corresponding human language – if this discipline is in place, end-user software can use a single variable to store the user's preferred language for the user interface, and then systematically retrieve properties in this language (until the user changes it). Even the chosen language makes sense to be a multilingual property: for example, choosing English from a Spanish interface needs a different string property value ('inglés') than from a German interface ('Englisch').
The second variation to instantiate property values is based on users and time: in principle, over time, each user can customize any property value (if allowed to do so through the end-user software user interface). When the end-user software calls the 'PropertyValueGet' API to retrieve a property's value, our single entry point engine will provide the property's value defined through previous 'PropertyValueSetAllow' and 'PropertyValueSetCommit' API calls only while no user customization occurs. Once user customization has occurred by calling the 'PropertyValuePerUserSetAllow' and 'PropertyValuePerUserSetCommit' APIs, then 'PropertyValueGet' will retrieve the user's customized value for the property.
Finally, we have to note that a property's value customization by a user can happen many times along time: we store each new value inside our finite state automaton, together with its registration timestamp. That is why the 'PropertyValueGet' API has an optional parameter named 'When'. If 'When' is not defined, PropertyValueGet retrieves the property's current value; however, if the 'When' parameter specifies a timestamp, the 'PropertyValueGet' API will retrieve the value the property had at that moment in time.
As this time-based instantiation mechanism allows to retrieve properties' values from the past, end-user software can be built to allow users to have a 'time machine' on their user interface, allowing them to reconfigure their software to operate based on customization data as it was in the past. This mechanism is in some sense similar to the 'system restore' functionality available in some operating systems; however, it brings this option into any end-user software based on our cloud-based time-limited transaction manager.
US Patent Requested