Patent Application
20050097133
1. Field of the Invention
The present invention relates generally to distributing computer software and, more particularly, to producing software distribution kit (SDK) volumes.
2. Related Art
Some computer vendors preinstall software, such as operating systems and application programs, on computers before shipping the computers to users. For example, it is common for a new personal computer (PC) to be delivered with word processor, Internet browser and spreadsheet software packages already installed on the PC's hard drive. If a user wishes, he or she can install additional software on the PC. Similarly, the user can upgrade the preinstalled software, such as when a new version of one of the preinstalled software packages becomes available. In either case, the user first obtains a “software distribution kit” (SDK), which the user then uses to install or upgrade the software.
SDKs are typically obtained by downloading them, e.g. from the Internet, or by purchasing them, e.g. from computer stores or software vendors. SDKs are available in various forms. For example, a downloaded SDK typically does not have any physical components. Instead, a downloaded SDK typically consists of one or more files that are copied from an Internet site directly to a PC's hard drive. On the other hand, a purchased SDK typically contains one or more physical volumes of removable, computer-readable media (“SDK volumes”) on which the files are distributed. A collection of one or more volumes of an SDK are referred to herein as an “SDK volume set.” Compact discs (CDs) are typically used as the SDK volumes, however other media types, such as digital versatile discs (DVDs, also known as digital video discs), can also be used.
As noted, SDK volumes store various types of files that are used to install software on a computer. The first volume of an SDK typically includes an installation program or script that is executed by a computer to install the software on the computer. Often, the computer's operating system has been configured to automatically execute this program or script when the first SDK volume is inserted into an appropriate drive connected to the computer. The installation program or script typically copies some or all of the remaining files from the SDK volume(s) to the computer's hard drive. However, installing software typically involves more than merely copying files to a computer's hard drive. In some cases, the installation program modifies the files as it copies them to the computer or it integrates the files with existing files on the computer. The installation program or script typically copies selected files to the computer only if the files do not already reside on the computer's hard drive, e.g. as a result of a previous installation of an earlier version of the software package or another software package. Which files on the SDK are processed by the installation program might also depend on installation options selected by the user. For example, if the user does not require all the features that are available in a software package, the user might select a “minimum” installation, which copies only a few files from the SDK to the computer. In contrast, a “full” installation typically copies more files to the computer. Some installation programs and scripts make configuration changes to the computer to “register” the newly installed software with the operating system. In addition, an installation program typically adds icons to a computer's user interface to enable a user to start the application program, read its documentation, etc.
Software producers often experience inventory problems due to the constantly changing mix of SDKs they must keep in stock to satisfy demand for the kits. This problem occurs, in part, because software development organizations release new software, and new versions of existing software, rather frequently. Each release requires a new SDK. In addition, software development organizations often release test versions of the software before releasing production versions of the software. Each test version also requires an SDK. Once the production version of a software package is released, any existing test versions of the software generally become obsolete. However, obsolete SDKs cannot always be discarded, because occasionally some customers or software development organizations need one or more historical versions of an SDK long after the SDK has become obsolete. Predicting which historical SDKs will be needed and when they will be needed are very difficult, so it is usually not possible to keep an appropriate number of historical SDKs in stock. Furthermore, the expected useful life of media sometimes limits how long SDKs remain reliable and, therefore, how long they can be stored in inventory.
As noted, the frequent release of new production and test versions of software leads to an ever-changing mix of SDKs in a software producer's inventory. Each new software package, each revision to an existing software package and each test version of a software package requires its software producer to inventory an additional SDK. For each volume of the additional SDK, a software development organization usually provides an SDK volume “master.” A software manufacturing organization then mass-produces SDK volumes from the master volume. If the SDK includes more than one volume, the software producer packages the appropriate SDK volumes together. In any case, the SDKs are then kept in inventory. If the software producer underestimates demand for a particular software package, the software producer might have difficulty providing enough SDKs in a timely manner. In such a case, the software producer typically uses the SDK volume master(s) to mass-produce additional copies of the SDK volume(s). On the other hand, if the software producer overestimates the demand, many SDKs might ultimately have to be discarded when they become obsolete.
In one aspect of the present invention, a system for producing a software distribution kit (SDK) volume, the SDK volume being a removable computer-readable volume storing a plurality of SDK component files, is disclosed. The system comprises at least one normalized file storage server configured to store SDK component files of a plurality of SDK volumes; and a database configured to identify the SDK component files of each SDK volume.
In another aspect of the present invention, a system for producing a software distribution kit (SDK) volume, the SDK volume being a removable computer-readable volume storing a plurality of SDK component files, is disclosed. The system comprises means for storing SDK component files of a plurality of SDK volumes; and means for identifying the SDK component files of each SDK volume.
In yet another aspect of the present invention, a method for producing a software distribution kit (SDK) volume, the SDK volume being a removable computer-readable volume storing a plurality of SDK component files, is disclosed. The method comprises for each of the plurality of SDK component files, if the SDK component file has not already been stored on a file storage server, storing the SDK component file on the file storage server; and storing in a database information correlating the stored SDK component files with the SDK volume.
In a further aspect of the present invention, a method for producing a software distribution kit (SDK) volume, the SDK volume being a removable computer-readable volume storing a plurality of SDK component files, is disclosed. The method comprises copying the plurality of SDK component files from a file storage server; creating an image of the SDK volume from the copied SDK component files; and writing the image to a writeable removable computer-readable volume.
The present invention is directed to producing software distribution kit (SDK) volumes where and when they are needed, thereby minimizing the need to inventory physical SDKs volumes in anticipation of a demand for the SDKs. As noted, SDKs comprise one or more SDK volumes, each of which contains various component files. In one embodiment, individual component files are stored in a library on a file storage server. When an SDK is added to the library, component files from SDK master(s) are copied to the library. The library also includes a database to store information about the SDKs, such as how many SDK volumes are in each SDK and which component files are in each SDK volume. In certain embodiments, the database also stores the name and version of each SDK, thereby enabling a user to browse the library and select an SDK, or an individual SDK volume, for production. The information contained in the database is then used to create an SDK containing the selected SDK volume(s). The SDK is provided on a computer-readable medium, such as a CD.
To prevent storing unnecessary copies of component files, the library preferably stores one copy of each unique component file. Such “normalized” storage of component files saves storage space because some SDK volumes contain files that are identical in content (not necessarily in name) to files contained in other SDK volumes. This is especially true of successive versions of a single software package, because many files remain unchanged from version to version of a software package. In addition, it is common for SDKs to include prerequisite software, such as run-time libraries. Many software packages require the same run-time libraries as other software packages, so SDKs for these software packages typically contain some redundant component files. Consequently, when SDK masters are added to the library, it is likely that copies of some of their component files have already been stored in the library. Optionally, data stored in the library can be compressed to further save storage space.
For simplicity, the invention is described with reference to CDs, but the invention also applies to any computer-readable medium or combination of media on which SDKs can be distributed. The media need not be read-only media, as long as SDKs can be produced on the media. For example, recordable DVDs (DVDRs) and DVD burners or ZIP disks and ZIP drives can be used to practice the invention. Therefore, in describing the present invention, the terms “SDK volume,” “CD,” “CD volume,” “SDK volume set” and “CD set” mean any appropriate medium or combination of media.
The administrator can, for example, mount an SDK volume master on a CD reader 112, so component files of the SDK volume master can be copied to one of the file storage servers 104-106. Alternatively, the administrator can use a workstation 114 to communicate with data management system 102 via network 108 and, thereby, interact with the data management system. The administrator can, for example, use a CD reader 116 connected to workstation 114 to mount an SDK volume master and add it to library 100.
In one embodiment, a processing server 118 and network shared storage 120 are included in library 100 to facilitate processing an SDK volume master. In one embodiment, data management system 102 instructs processing server 118 to process the SDK volume master. Data management system 102 communicates with processing server 118 through network shared storage 120. For example, management system 102 can send processing server 118 the name of an SDK and a path to a device, such CD reader 112 or 116, on which the SDK volume master is mounted. Processing server 118 reads the SDK volume master and copies appropriate component files, e.g., normalized files, to one of the file storage servers 104-106. Processing server 118 also creates database records on one of the file storage servers 104-106 to reflect the added SDK volume.
A user, e.g. of a workstation 122, can communicate with data management system 102 via network 108 to request that an SDK volume or volume set be produced. In one embodiment, the appropriate component files are copied from the file storage server 104-106 that is nearest workstation 122 on network 108. The files are then written to a CD on a local CD burner 124 connected to the workstation 122. Alternatively, workstation 122 can send a command to a CD production server 126 to produce the SDK volume or volume set. In this case, CD production server 126 can fetch the component files from workstation 122 or the nearest file storage server 104-106 and use a robotic CD burner 128 to burn one or more copies of the SDK volume or volume set.
The embodiment of library 100 illustrated in
The other portion of the database, referred to as component catalog 206, catalogs the component files stored in library 100. Component catalog 206 identifies, for example, which component files make up each SDK volume and how many volumes are in each SDK volume set. In the embodiment illustrated in
Automatic replication ensures that all the file storage servers contain essentially the same contents. That is, if an SDK is added to one of the file storage servers, its component files are automatically copied (replicated) to the other file storage servers. This replication enables any file storage server to fulfill any request. Such an arrangement can, for example, continue to function, even if some of the file storage servers fail. Geographically distributing the file storage servers places the servers closer to potential users, thereby reducing the time required to transfer component files from one of the file storage servers to a user's computer.
Also as previously noted, to add an SDK to library 100, an administrator 208 mounts one or more SDK volume masters 210 and enters SDK set information 212 into data management system 102, such as through user interface 110 and CD reader 112 (
In one embodiment of library 100, a file extractor 216 executes on workstation 114 (
Data management system 102 includes a web server 220 that makes SDK catalog 202 available for browsing. To produce an SDK volume or volume set, user 214 uses a browser 222 in workstation 112 (
The two portions of the database, SDK catalog 202 and component catalog 206, are described below with reference to
As will become evident from the description of the two catalogs 202 and 206, they are functionally somewhat redundant, and in other embodiments they could be combined into one catalog. However, SDK catalog 202 is preferably stored separate from component catalog 206 to provide faster access to the SDK catalog, especially by users browsing the SDK catalog. As would be appreciated by one of ordinary skill in the art, computer systems can be “tuned” to perform various functions. For example, data management system 102 can be tuned to optimize database performance, and file storage servers 104-106 can be tuned to optimize file service performance.
SDK catalog 202 catalogs the SDKs and SDK volumes in the library 100. For each SDK, SDK catalog 202 contains an “SDK catalog record” 304 (
Preferably, database 300 normalizes information about SDK volumes. That is, if two or more SDKs include a common SDK volume, database 300 contains only one record 1306 to represent the SDK volume. This is illustrated in
With continued reference to
In the embodiment illustrated in
Each SDK volume contains one or more component files 206, each represented by an SDK file record 328A and 328B. As shown by arrows 330A and 330B, an SDK volume record 316C is linked to its corresponding SDK file record(s) 328. Furthermore, each SDK file record 328 is linked to its corresponding component file record 324, as represented by arrows 332. Thus, if an SDK volume record 316 can be identified, its constituent component file(s) 204 can be located on file storage servers 104-106. Similarly, if an SDK set record 314 can be identified, its constituent SDK volume records 316 can be located. These records and links are used by SDK builder 224 (
If two or more SDK volumes include a common component file 204, each of the SDK volume has its own SDK file record 328, because the component file might appear at a different location on each of the SDK volumes. This situation is illustrated in
When an SDK volume is added to library 100, file extractor 216 (
The records in database 300 that represent SDKs and SDK volumes store respective part numbers for the SDKs and SDK volumes. Thus, it is possible to search SDK catalog records 304 or SDK set records 314 for a particular SDK part number. As previously noted, once the record representing a desired SDK is found, records representing its constituent SDK volumes can also be found. Similarly, it is possible to search SDK volume catalog records 306 or SDK volume records 316 for a particular SDK volume part number. Once the record representing a desired SDK volume is found, records representing its constituent component files can be found. In addition, once the record representing the desired SDK volume is found, is possible to find the record(s) representing SDK(s) that include this SDK volume.
As previously noted, when an SDK is added to library 100, file extractor 216 reads SDK volume master(s) 210 and copies unique files from the volume master to one of the file storage servers 104-106. A brief description of the layout of one embodiment of a CD volume is provided below to facilitate understanding how file extractor 216 operates.
When file extractor 216 reads an SDK volume master 210, it treats the header information 402 of the volume master as a file. If the file storage servers 104-106 do not already store a component file 204 with the same contents as the header information 402 of the CD, file extractor 216 creates a new component file 204 and copies the header information to one of the file storage servers 104-106. Thus, file extractor 216 creates a new component file 204. In addition, file extractor 216 creates an SDK file record 328 and a component file record 324 to correspond to the newly created component file 204. On the other hand, if the contents of an existing component file 204 is identical to the header information 402 of the CD, file extractor 216 creates an SDK file record 328 and links the SDK file record to the existing component file record 324 that represents the existing component file. If an existing component file 204 is identical in contents to the header information 402 of the CD, it is likely that remaining contents 404 of the CD are also already stored in component files on file storage servers 104-106. In either case, file extractor 216 links the newly created SDK file record 328 with the appropriate SDK volume record 316.
Similarly, file extractor 216 examines each file 406 in the second portion 404 of the CD to determine if the contents of the file is the same as that of the component files 204 currently on the file storage servers 104-106. If the file storage servers 104-106 do not already store a component file 204 with the same contents as the file 406, file extractor 216 creates a new component file 204 by copying the file 406 from the CD to one of the file storage servers. File extractor 216 also creates an SDK file record 328 and a component file record 324 to correspond to the newly created component file 204. On the other hand, if an existing component file 204 is identical in contents to the file 406, file extractor 216 creates an SDK file record 328 and links the SDK file record to the existing component file record 324 that represents the existing component file. In either case, file extractor 216 links the newly created SDK file record 328 with the appropriate SDK volume record 316.
Storing the first portion 402 of the CD as a component file 204 on file storage servers 104-106 facilitates later producing an SDK volume. For example, SDK builder 224 need not be concerned about the file structure of the CD, component file names, attributes, etc., because the root directory and other file structure overhead data stored in the first portion of the CD 402 will be written to the beginning of the newly created SDK volume.
Component files 204 on file storage servers 104-106 are not necessarily given the same names as files on SDK volume master 210, from which they are copied. Instead, when file extractor 216 creates a component file 204, the file extractor generates a unique filename for the component file. For example, many SDK volumes include files named “SETUP.EXE,” but the contents of these files are likely to vary from SDK volume to SDK volume. Generating file names for component files 204 avoids filename collisions and confusion about the contents of the component files.
An overview of database 300 is provided above in conjunction with
Description field 504 can include, for example: a text name for the software package distributed by the SDK; an indication of whether the SDK contains a test or production version of the software package; and the SDK's release date and and-of-life date. Other fields can, of course, be added to SDK catalog record 304 to meet business needs of library 100, such as to keep track of which software engineering organization contributed an SDK or how many copies of the SDK were produced by the library.
An SDK volume catalog record 306 represents one SDK volume. Each SDK volume catalog record 306 preferably includes four fields: a part number of the SDK volume 510; a description 512 and a version number 514 of the SDK volume; and an operating system identifier 516, if the SDK volume is operating system specific. The SDK volume part number field 510 is the key field for the SDK volume catalog table. Of course, other fields can be added to SDK volume catalog record 306 to meet business needs of library 100.
Because there can be a many-to-many relationship between SDKs and SDK volumes, SDK-to-SDK volume records 518 are used to link the two types of catalog records 304 and 306, as is well-known in the art. Each SDK-to-SDK volume record 518 preferably includes four fields: a link key 520 (containing a system-generated unique key); a part number of SDK volume 522; a part number of SDK 524; and an SDK volume order field 526 (explained below). Other fields can, of course, be added.
As noted above, and as is well-known in the art, records in one table can be related to records in another table by keys. This is illustrated by arrows 528 and 530. Thus, linking record 518 is related to a particular SDK catalog record 304 by storing the SDK's part number in field 524. Similarly, the linking record 518 is related to a particular SDK volume catalog record 306 by storing the SDK volume's part number in field 522.
Because an SDK can include several volumes, one SDK catalog record 304 can be associated with several SDK volume catalog records 306. This is illustrated in
As is well known in the relational database art, collections of table rows, i.e. subsets of records, can be formed by querying or filtering a table by one or more criteria. For example, all SDK volume catalog records 306 associated with a particular SDK can be identified by querying the linking table 518 for all records that contain the SDK's part number in field 524. The resulting linking records 518 can then be sorted by their SDK volume order fields 526 to produce an ordered list. Then, the SDK volume part number fields 522 can be read from this ordered list to locate the SDK volume catalog records 306. This yields records representing all the volumes of the SDK in the order in which they are to appear in the SDK.
Each component file 204 is represented by a component file record 324. Field 612 preferably contains a unique 16-byte, system-generated data key. Alphanumeric characters are used for the bytes. The data key is used to calculate a path to the component file 204A. File extractor 216, SDK builder 224 and robotic CD burner 128 can use this path to access the component file 204, as follows. The data key is preferably divided by slashes into two- and four-character segments in a 4-4-4-2-2 pattern. The name of one of the file storage servers 104-106 and a device name, for example “\\fileserver27\d$\,” are prepended to the resulting string. Then, “.dat” is appended to the string. Thus, for example, “0123456789101112” becomes “\\fileserver27\d$\0123\4567\8910\11\12.dat.” Dividing the data key in this fashion distributes component files 204 across plural directories and ensures that no single directory is overburdened.
As previously noted, when file extractor 216 processes SDK volume master 210, the file extractor creates component files on file storage servers 104-106, but only for unique files. Rather than actually comparing the contents of each file on SDK volume master 210 with every file on file storage servers 104-106, file extractor 216 calculates a “signature” for each file on the volume master. Each component file record 324 contains a signature of its corresponding component file 204. File extractor 216 compares the signatures of the files on SDK volume master 210 to the signatures stored in component file records 324 to determine if the respective files contain identical contents. The signature is preferably a combination of an MD5 checksum of the file and the file's size. Thus, each component file record 324 includes a “MD5 checksum of file” field 614 and a “file size” field 616. The MD5 checksum and file size fields 614 and 616 can also be used by SDK builder 224 or robotic CD burner 128 to verify that a CD burner operation completed without error.
As previously discussed, SDK file records 328 link SDK volume records 316 with component filed records 324. A “file order” field 618 indicates the order in which component file 204A is to be copied to the produced SDK volume.
Descriptions of the database 300 and functional components of the library 100 are provided above. Additional information about file storage servers 104-106, database 300, data management system 102, normalization and replication are provided in commonly-owned U.S. Pat. Nos. 6,202,070 and 6,038,399, both of which are hereby incorporated by reference herein. A description of a procedure for adding an SDK to the library is provided here with reference to
At 710, the flowchart 700 begins a loop that is processed once for each SDK volume master of the SDK. At 710, information is read from an SDK volume master. This information can be used to augment the SDK or SDK volume records. At 712, an image copy of the SDK volume master is created, so later, individual files of the SDK volume master can be extracted. The image copy can be stored, for example, on network shared storage. At 714, a job file is created for this SDK volume. Alternatively, instead of creating an image of the SDK volume master at 712, a path to the mounted SDK volume master can be included in the job file created at 714.
The file extractor 216 (
At 910, an MD5 checksum is calculated for a file of the SDK volume master. In addition, the size of the file is obtained. The MD5 checksum and file size are used as a signature of the file. The first time through this loop, header information, instead of a file, on the SDK volume master is processed. At 912, a search is made of the component file records for a component file having a signature identical to the file (or header information) on the SDK volume master.
At 914, if an identical signature is found, indicating that an identical file is already stored in the library, control passes to 924. Otherwise, at 916, a component file record is created with a unique 16-byte data key. At 918, the file is copied from the SDK volume master to a path calculated from the 16-byte data key, as described above. At 920, if the copy is successful, control passes to 924. Otherwise, an error is indicated at 922. Success of the copy operation can be gauged by, for example, calculating an MD5 checksum and size of the component file and comparing these values to corresponding values for the file that was copied from the SDK volume master. At 924, an SDK file record is created. At 926, if more files remain to be processed on the SDK volume master, control returns to 910. Otherwise, the flowchart completes at 928.
Procedures for creating an SDK, i.e. an SDK volume set, or a single SDK volume will now be described.
In
At 1012, the part number of each SDK volume of the SDK is obtained by filtering and sorting the SDK to SDK volume linking records. At 1014, if the SDK is not to be produced locally, control passes to 1016. At 1016, the part numbers are sent to the robotic CD burner. (Operation of the robotic CD burner is described below with reference to
The flowchart 1000 then begins a loop that is processed once for each volume in the SDK. At 1022, a list of files on the SDK volume is fetched by filtering and sorting the SDK file records. At 1024, one of these files is copied from the selected or default file storage server, and at 1026 the copied file is appended to an image buffer. If the file size is less than a whole multiple of the SDK volume's sector size, the file is padded to occupy a whole number of sectors. Thus, each file begins on a sector boundary of the produced SDK volume. At 1028, if more files remain, control returns to 1024. Otherwise, control passes to 1030, where the SDK volume is produced, e.g. by burning it onto a CD. At 1032, if more SDK volumes remain in the SDK volume set, control returns to 1022. Otherwise, the flowchart ends at 1034.
A user may not wish, or may not be able, to produce SDK volumes with the user's computer. For example, the user's computer might not include a CD burner, or the user might require a large number of copies of an SDK. In flowchart 1000, at 1014, a decision is made regarding producing the SDK locally, i.e. on the user's computer, or via a central robotic CD burner. If a decision is made to use the robotic CD burner, at 1016 part number(s) of the SDK or SDK volume(s) to be produced are sent to the robotic CD burner. Alternatively, each component file or the entire image buffer can be sent to the robotic burner.
At 1108, a list of files on the SDK volume is fetched. The flowchart 1100 then begins a loop that is processed once for each component file of the SDK volume. At 1110, a component file is copied from one of the file storage servers, preferably the file storage server nearest the robotic CD burner. At 1112, the copied file is appended to an image buffer. As described above, the copied file is padded so it occupies a whole number of sectors and begins on a sector boundary. At 1114, if there are more component files for this SDK volume, control returns to 1110, otherwise control passes to 1116. At 1116, one or more CDs are burned, depending on the number of copies of the SDK volume requested by the user. At 1118, if there are more SDK volumes in this SDK, control returns to 1108, otherwise the flowchart ends at 1120.
SDK masters that are added to the library need not be stored on the same medium/media as corresponding SDKs produced by the library. For example, SDK masters can be stored on a hard disk as images of CDs or other media when they are read by the file extractor. In addition, the SDK masters can be compressed, such as InstallShield archives or ZIP files, and the file extractor can optionally decompress the SDK masters as they are processed. SDK master, therefore, means an archive or other package of multiple files.
Some conventional computer manufacturing systems store images of hard drives that already have software installed on them. Such systems are used by computer manufacturers to preinstall software on computers before the computers are delivered to users. Such systems operate by copying an entire disk image or portions thereof to a hard drive or a partition of the hard drive, essentially installing the software on the hard drive. Thus, when a computer containing the hard drive is started (“booted”), the computer behaves as though an SDK had been installed on it.
In contrast, the present invention does not install SDKs or files on target computers. The invention provides methods and systems for producing SDKs on demand. SDKs are different than hard drives with software installed on them. As previously noted, SDKs include files, some or all of which are selectively copied to a hard drive during software installation. SDKs are not merely images of hard drives. Furthermore, SDKs typically include software installation programs or scripts that are executed by computers to install the software on the computers. In contrast, a hard disk with software preinstalled on it does not need such a software installation program. Therefore, a system that produces SDKs is different than a system that produces hard drives with software preinstalled on them.
The methods and systems for producing SDKs and other aspects of the present invention are preferably implemented in software or firmware than can be stored in a memory and control operation of a computer such as a personal computer, workstation, mainframe, control processor, or microprocessor control processor embedded in another system. The memory can, but need not, be part of a computer. Alternatively, the memory can be part of an integrated circuit that includes the control processor or microprocessor. The software or firmware can be stored on a removable or fixed computer-readable medium, such as a CD-ROM, CD-RW, DVD-ROM, DVD-RW, ZIP disk, hard disk or floppy disk. In addition, the software or firmware can be transmitted over a wireless or wired communication link, such as a public or private local or wide area computer network, including the Internet, or a telephone network.
Alternatively, the methods and systems for producing SDKs and other aspects of the present invention can be implemented in hardware. For example, the SDK builder can be implemented in a single integrated circuit or in a combination of integrated and/or discrete circuits and embedded in a network-connectable CD burner. All or portions of the methods and systems for producing SDKs can be implemented as combinatorial logic, an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA).
