Patent Application
20080127162
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates generally to application software. More particularly, this invention relates to a cross-platform configuration system for configuring application software.
Computer registry files generally include one or more machine configuration files and user profiles, which store information necessary to configure the computer for one or more users, applications, and hardware devices. The information is continually or periodically referenced by an operating system and application software during operation. The information includes, but is not limited to, profiles of each user, applications installed on the computer, types of documents that each user can create, property settings for folders and icons, installed hardware, and ports that are being used. Whenever there is a change to the settings for hardware, software, or users, the changes are reflected and stored in registry files.
Registry files are generally platform-dependent. For example, many existing computing systems use Windows Registry for managing registry files. Windows Registry is used exclusively on Windows® platforms and cannot be used for a system running a different operating system, e.g., a Unix or a Linux operating system. Thus, conventional registry files are generally managed on a machine-by-machine basis and are difficult to transfer across different platforms.
Further, registry files often contain sensitive information, e.g. user login information or personal data, which needs to be protected from unauthorized access.
A cross-platform registry system manages configuration information for application software. In one embodiment, a process includes, but is not limited to, storing configuration information in a configuration file using a cross-platform markup language, the configuration information including configuration data associated with the operating environment and user data associated with the application, and configuring the application by accessing the configuration file without using a registry of an operating environment in which the application is running.
Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.
A cross-platform registry system for managing registry information is described herein. In the following description, numerous details are set forth to provide a more thorough explanation of embodiments of the present invention. It will be apparent, however, to one skilled in the art, that embodiments of the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring embodiments of the present invention.
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment.
Accordingly, a configuration file that is cross-platform is designed to configure an application without having to rely on a platform dependent configuration mechanism, such as, for example, a registry of an operating system (OS) (e.g., Windows Registry of Windows operating system available from Microsoft). In one embodiment, a configuration file includes information similar to those stored in a registry of an OS, but is specifically associated with a particular application. This configuration file is cross-platform and portable across a variety of different platforms. In other words, this configuration file is used to simulate a registry associated with an application, herein also referred to as an Easy Registry because it is “easy” to use across multiple platforms. Similarly, a configuration file sometimes is referred to a registry file for the Easy Registry purposes, but it is not the same as a register file of a registry of an OS.
Easy Registry is a cross-platform register system that can be easily deployed on different platforms that execute different operating systems. Easy Registry provides machine-specific configuration data and user-specific data to application software that may be ported to different platforms. An example of such application software is the SAP Business One, which is a product of SAP AG located in Germany. The machine-specific data and user-specific data are stored in certain cross-platform markup languages such as an extensible markup language (XML) format. As a result, Easy Registry reduces the overhead in porting registry information to different platforms.
Easy Registry 120 includes a generalized (e.g., cross-platform) interface 130, an XML processing unit 140, and an XML file I/O 150. XML file I/O 150 accesses registry files 125 and reads an XML parser 160, e.g., Xerces, which is an open-source XML parser. XML file I/O 150 reads registry files 125 and forwards the files to XML processing unit 140. XML processing unit 140 maps data items in registry files 125 onto an internal memory structure that has the same structure of the data trees of registry files 125. The internal memory structure may be implemented in a random access memory (RAM) that is static, dynamic, or any suitable type, a flash memory, a disk, or other types of machine-readable storage media. The mapping allocates memory space to the data items in the data trees and thus avoids having to access registry files 125 each time a data item is accessed. The internal memory structure stores data items and their associated attributes. The associated attributes include, but are not limited to, a data format of the data item (e.g., binary, decimal, unsigned long, Boolean, or character string). During the mapping, XML processing unit 140 uses XML parser 160 to parse the data items, e.g., checking syntactic errors in the XML code. If no syntactic error is detected, the entire registry files 125 will be loaded into the memory. At this point, the registry information is ready for access by application software 110. It is understood that the components of Easy Registry 120 are shown for illustration purposes only and other configurations may exist.
If application software 110 is ported to a different platform, e.g., a different machine running a different version of the operating system or a different machine running an entirely different operating system, registry files 125 can also be ported without any change. The components inside Easy Registry 120, as shown in
Registry files 125 can be directly edited by any XML editor that runs on any platform. Registry files 125 can also be indirectly modified by application software 110. For example, during the operation of application software 110, a user may update his/her preferred background setting in the graphical user interface (GUI). To record the changed setting in registry files 125, application software 110 submits a write request through generalized interface 130 to update the corresponding data item in the internal memory structure. The write request includes a value of the data item, the attributes of the data item, and a path of the data item in the data tree. The change is also saved in registry files 125 to ensure consistency of the data items in the memory and in the registry file. In another example, a new user may be added to the list of authorized users for application software 110. To create the new user's file into registry files 125, application software 110 submits a write request through generalized interface 130 to add a new registry file that contain the user data of the new user. The new registry file is saved in the internal memory structure and in registry files 125. Note that some or all of the components or modules as shown in
A sample registry file 30 is shown in
In the example of
To write a data item, at block 450, application software 110 submits the full path of the data item and its associated attributes to Easy Registry 120 through generalized interface 130. At block 460, XML processing unit 140 stores the data value and its associated attributes into the specified path in the internal memory structure. To ensure consistency between the memory and registry files 125, at block 470, XML file I/O 140 writes the data item and its associated attributes into registry files 125 through XML file I/O 150. The data item and its associated attributes are written into a location in the corresponding data path of the XML data tree. It is understood that the read and write operations can occur in any order and during any time application software 110 operates. Other operations may also be performed.
Note that while
As shown in
The bus 502 interconnects these various components together and also interconnects these components 503, 507, 505, and 506 to a display controller and display device 508, as well as to input/output (I/O) devices 510, which may be mice, keyboards, modems, network interfaces, printers, and other devices which are well-known in the art. Typically, the input/output devices 510 are coupled to the system through input/output controllers 509.
The volatile RAM 505 is typically implemented as dynamic RAM (DRAM) which requires power continuously in order to refresh or maintain the data in the memory. The non-volatile memory 506 is typically a magnetic hard drive, a magnetic optical drive, an optical drive, or a DVD RAM or other type of memory system which maintains data even after power is removed from the system. Typically the non-volatile memory will also be a random access memory, although this is not required.
While
Thus, a cross-platform configuration system has been described herein. Portions of what was described above may be implemented with logic circuitry such as a dedicated logic circuit or with a microcontroller or other form of processing core that executes program code instructions. Thus processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine that executes these instructions to perform certain functions. In this context, a “machine” may be a machine that converts intermediate form (or “abstract”) instructions into processor specific instructions (e.g., an abstract execution environment such as a “virtual machine” (e.g., a Java Virtual Machine), an interpreter, a Common Language Runtime, a high-level language virtual machine, etc.)), and/or, electronic circuitry disposed on a semiconductor chip (e.g., “logic circuitry” implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative to a machine or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code.
It is believed that processes taught by the discussion above may also be described in source level program code in various object-orientated or non-object-orientated computer programming languages (e.g., Java, C#, VB, Python, C, C++, J#, APL, Cobol, ABAP, Fortran, Pascal, Perl, etc.) supported by various software development frameworks (e.g., Microsoft Corporation's .NET, Mono, Java, Oracle Corporation's Fusion, etc.). The source level program code may be converted into an intermediate form of program code (such as Java byte code, Microsoft Intermediate Language, etc.) that is understandable to an abstract execution environment (e.g., a Java Virtual Machine, a Common Language Runtime, a high-level language virtual machine, an interpreter, etc.), or a more specific form of program code that is targeted for a specific processor.
An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a propagation medium (e.g., via a communication link (e.g., a network connection)).
In the foregoing specification, embodiments of the invention have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
