The present invention relates to a method of operating a computing device, and in particular to a method for operating such a device in a manner which allows a plurality of developers to create and distribute parts or components of a customisable software product, whilst offering relative assurance that a complete and coherent whole of the software product can be assembled from the parts or components.
A customisable software product may be defined as one where recipients receive all or part of the source code used to build the software product along with the corresponding binaries or executables, thereby enabling the recipients to modify the software to their own requirements.
This definition of a customisable software product includes both open source software and free software. It also includes products where the recipients of the source code and the software comprise a restricted group. For example, the Symbian OS operating system developed by Symbian Ltd of London is a customisable software product, since the authorised recipients of the operating system receive all or part of the source code used to build the software along with its binaries or executables, thereby enabling them to modify the software to their own requirements.
When any body of software under continual development is released on a regular basis, there are generally in each release only relatively small changes to certain parts of the software body as a whole; i.e. the bulk of the software body often remains unchanged from one release to the next.
However, in order to ensure consistency and uniformity amongst all recipients of the releases, it is commonplace for the whole body to be completely reconstructed and redistributed in its entirety for each release. This is usually achieved either by copying the installation files to physical media, such as CD-ROM or other non-volatile storage media, or by making the installation files available for download via the Internet or other data transfer medium. All of the original software files are included in the update, even those that have not changed since any previous release of the software. However, for large software bodies, such as computing device operating systems, this can mean the distribution of an unnecessarily large number of CD-ROMs for each release, or if the Internet is used for downloaded distribution, many hours or even days of connection time to download the files.
This method of disseminating changes to the software body is commonly referred to as monolithic distribution. Its key advantage is that because it effectively builds the software in its entirety each time, it provides a common reference platform that is, in essence, guaranteed to work for all recipients, irrespective of how any recipient has modified the previous release. This distribution method is generally regarded as the most common method of releasing updates for any type of software.
An alternative method for the distribution of a release of updated software is for only those parts of the software which are functionally different from the previous version to be distributed, independently of the whole, with the entire body of software then being reconstructed by the recipient as needed. This method of disseminating changes may be referred to as incremental distribution. Its most obvious advantage is that it is quicker and more efficient than monolithic distribution because a smaller amount of data needs to be distributed for each release. Other significant advantages arise from the fact that incremental distribution relies on the division of the whole body of software into independent parts, generally called components, the existence of which enables the recipients to preserve as much as possible of the investment that they may have made in modifying a previous release. Incremental distribution enables this in two ways: firstly, because it distributes precisely what is needed to update the software product and secondly, because recipients may selectively decide to discard any component updates which are not needed for their respective customisation of the software product.
An overview of re-release and distribution of software updates has been compiled by Colin Percival of the Computing Laboratory at Oxford University. This overview can be found at http://www.daemonology.net/freebsd-update/binup.html, and outlines many of the problems and difficulties in this area. However, Percival has not found any methods suitable for use with customisable software products as referred to above. Two superficially similar software update methods that are described in the overview are sufficiently well-known to be worth mentioning in more detail here:
However, the release of such service packs does not fall into the problem domain this invention seeks to address because the Microsoft products to which the service packs are applied cannot be regarded as customisable software products. Most importantly, no source code is included in the service packs or is distributed to users. Consequently, users are not able to modify the software source code in order to customise the product to their own requirement; they are only able to customise the behaviour of the product, within the limits permitted by the product designers and authors. In particular, there is no control of the update process when installing a service pack, and users cannot decide upon actual selective adoption of any portion of a service pack.
However, such package management systems also do not fall into the problem domain this invention seeks to address. This is because companies such as Red Hat and organisations such as Debian do not themselves produce customisable software products. What they do is to aggregate and integrate independent and separate customisable software products from multiple sources and authors, and package these independently produced components in such a way that recipients can successfully integrate them. There is no need with Linux distributions to offer any guarantees about the relationship between a whole body of software as shipped and the whole body of software that the recipients of their component releases may be using.
There is therefore a clear distinction in the way that components have to be delineated and then managed by operating system authors and distributors who design, write and build their software as an integrated whole, and the way that components are accepted and redistributed by Linux vendors who, for example, assemble an operating system from customisable software products produced by other people and have no need to incrementally update the whole body of the software they ship in a consistent and coherent manner.
It can be appreciated from the above description that the key advantage of a monolithic distribution is that it is, in essence, guaranteed to work for all recipients irrespective of how they have modified the previous release.
Monolithic distribution is shown diagrammatically in
While incremental distribution overcomes many of the difficulties imposed by monolithic distribution and therefore offers potential benefits in terms of speed and efficiency, it gives rise to its own concerns.
Incremental distribution has in certain respects potentially higher risks than monolithic distribution in that there is more that can go wrong for the software producer, because only partial source code is being distributed. This is especially true for large bodies of software such as operating systems. For example, additional source files (which are new rather than unchanged) may accidentally be omitted from the release. Or, where co-dependencies between components are very complex, failure to release any one component may result in the recipient finding that source code or header file files may exist as multiple versions in the release.
Another source of risk arises from one of the reasons for the attractiveness of incremental distribution for recipients of software, namely that the recipients are able to pick and choose which components they take on the basis of what they actually need and use. Because of this, the authors or distributors will be faced with the near certainty that their product will be used in multiple different configurations by different recipients. The authors or distributors have no way of telling whether any particular module has been updated or customised, and are faced with the prospect of each recipient build in the field having a unique mix of customised components, updated components and original components. This decreases their control of the quality of their product and increases their support costs.
Incremental distribution entails additional risk even when producers make no mistakes in their release process, and even if recipients take every component in the release. Because it does not start from a ‘clean’ base release, the release cannot offer the author or distributor an equivalent level of assurance as can be provided with the monolithic distribution method; that all recipients are building precisely the same version of the software. This is because it is the recipient and not the author or distributor who is responsible for merging the new and old distributions and then rebuilding the body of software for actual use.
Furthermore, the accidental complexities of the build process, and its dependence on specific and largely uncontrollable aspects of the configuration of the local system used for the rebuilding, are such that it is not always possible to guarantee the integrity of the entire body of rebuilt software for any recipient.
Additionally, the division of a body of software into components is essential for incremental distribution: it is not possible to employ this method if the software can only be built monolithically. However, as will be apparent to persons familiar with this art, even with good modular architecture, dividing a large body of software into independently distributable components is not a straightforward operation. Determining the many relationships and interdependencies between different areas and components is a difficult and time-consuming process.
Moreover, the actual task of identifying only those parts of the software that need to be included in an incremental distribution is non-trivial. It is regarded as a high risk procedure to try and optimise this manually. Colin Percival of the Computing Laboratory at Oxford University points out in relation to manual efforts that “they all attempt to minimise the number of files updated, and they all include human participation in this effort. This raises a significant danger of error; even under the best of conditions, humans make mistakes, and the task of determining which files out of a given list had been affected by a given source code patch requires detailed knowledge of how the files are built.”
In relation to this last point, it should be noted that while manual optimisation may be risky, automatic optimisation of a release is also not easy to implement. This is because it can be quite difficult to automatically distinguish between functional and non-functional changes. An example of a nonfunctional change in a file is where spelling mistakes in the comments attached to source code have been corrected. Such a correction clearly changes the contents of the source code, but in a non-functional way. When the source code is recompiled, this will change the timestamps contained in an associated object file, again in a non-functional way. The use of automated software tools which automatically check files for differences (such as ‘Diff’ and methods such as providing digests of files in order to uncover changed components, will all flag both the source code and the object file as altered. The consequent failure to optimise incremental distribution results in the distribution of items that do not need to be updated.
However, there is some prior art teaching on how to minimise this effect. For example, Percival describes one method for avoiding the re-release of binary files simply because the internal timestamp has changed by building the file from the same source twice but with a different system date each time, and then doing a byte-for-byte comparison to discover the place where the datestamp is stored. This makes it possible to exclude such areas of files when comparing past and present releases, and therefore avoid false positives when identifying changed components. Symbian Ltd has also previously published as part of the Symbian OS operating system a tool called ‘evalid’, which does a byte-for-byte comparison of files but ignores these unimportant differences. However, it should be noted that all these solutions to the problem of identifying those parts that need to be included in an update still rely on file comparisons to function.
Some of the end results arising from the inherent problems of incremental distribution are shown diagrammatically in
It is clear from the above discussion that there is no available method of reconciling the advantages of the monolithic distribution method with the advantages of the incremental distribution method.
Accordingly, it is an object of the present invention to provide an incremental distribution method which can provide a level of assurance equal to that of the monolithic distribution method so as to ensure that a set of component releases can completely and accurately represent a whole body of software.
The invention further includes an optimisation of the incremental distribution method enabling authors, distributors and recipients to distinguish between functional and non-functional changes, which ensures that no unnecessary content is distributed in a release, thus maximising both efficiency and convenience.
According to a first aspect of the present invention there is provided a method
According to a second aspect of the present invention there is provided a computing device arranged to operate in accordance with a method according to the first aspect.
According to a third aspect of the present invention there is provided computer software for causing a computing device according to the second aspect to operate in accordance with the method of the first aspect.
An embodiment of the present invention will now be described, by way of further example only, with reference to the accompanying drawings, in which:—
In the embodiment of the present invention described below, the component releases are made, and the relative guarantees are enforced, by a set of automated tools. The following assumptions are made for the purposes of this embodiment of the invention:
These relationships are shown in
Note that in a preferred implementation of this invention used by Symbian Ltd the release metadata also contains a list of the other components present in the development environment when the release was made. This ‘environment’ information, combined with the enforced constraints, enables the precise environment of any release to be recreated on another computer, based solely on the newly made releases, plus previously made releases.
The following pseudocode describes the releasing process more precisely:
Whenever the release is abandoned in the above algorithm the releaser needs to fix the concern which caused the abandonment before making another attempt. An optimisation would be for the process to continue checking for further errors instead of abandoning, but not to make any releases, in the same manner that code compilers carry on compiling when they encounter errors rather then stopping on the first one they find. This would allow the releaser to reduce the number of iterations for each release.
Once the release has been made, the recipient then obtains and installs the new release from the shared medium using a complementary set of tools. The key point of this embodiment is that the releases must have been made using the above algorithm; this guarantees that there is no possibility of gaps, no overlap, and that no components will be irreproducible from releases on the shared medium. The algorithm in the following pseudocode assumes that the recipient already has a previous release and simply requires the updated components since that release.
This algorithm functions even if the recipient has skipped releases. It also functions for recipients who have not taken any previous releases and for recipients desirous of obtaining a ‘clean’ release, provided that in such a case all components would be marked as changed.
There is in a preferred implementation of the invention an optimisation in the releaser pseudocode algorithm at line 26. This step represents where the present invention checks, for each file which is to remain unchanged, that the version on the releaser developer drive is identical to the version on the shared medium.
The basis of this optimisation is that the data in a file can be mathematically manipulated to produce a single number that represents the contents of that file, variously termed a message digest, a hash or a checksum. Depending on the algorithm used to compute this number, it is exceedingly unlikely that two files will have the same message digest. Hence, it is possible to compare the digests for two files instead of comparing the files themselves in order to verify identity. A number of suitable algorithms exist in the public domain, such as the well-known MD5 algorithm. It is common practice to distribute such digests along with files to enable recipients to verify identity.
Therefore, in a preferred optimisation of the invention, it is proposed to include in the information contained in the component database on the shared medium a digest of the significant portions of each file included in that component, to calculate a similar digest for each file to remain unchanged, and to match these two digests against each other to verify identity. Such a distribution of a digest not of the whole file but only of the significant portions of a file is another advantageous aspect of this invention. It will be appreciated that a digest-to-digest comparison is a quicker and more efficient method than a file-to-file comparison, and does not require access to any file apart from the file being checked in order to function properly. In a preferred implementation, the method is as follows:
A number of different mechanisms for propagating the data identifying each file format and the rules for deciding the important area to all the recipients are possible, such as incorporating the format descriptions in the tools or alternatively storing them on the shared medium in tool-readable form.
As well as enabling releasers to efficiently identify changed files, this optimisation also allows recipients to check the integrity of their version of the body of software; they can simply compute message digests of the significant portions of files and then check that each digest matches the one stored for the same file in the same release in the component database. One possible algorithm for achieving this is as follows:
The present invention is considered to provide the following exemplary significant advantages over the known methods for distributing a body of software
Although the present invention has been described with reference to particular embodiments, it will be appreciated that modifications may be effected whilst remaining within the scope of the present invention as defined by the appended claims.
Number | Date | Country | Kind |
---|---|---|---|
0411197.7 | May 2004 | GB | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/GB2005/001921 | 5/18/2005 | WO | 00 | 12/3/2007 |