FORM 2 THE PATENTS ACT 1970 [39 OF 1970] & THE PATENTS RULES, 2003 COMPLETE SPECIFICATION [See Section 10; rule 13] "NETWORK BASED SOFTWARE EXTENSIONS" MICROSOFT CORPORATION, a corporation of the State of Washington, which has a principal place of business at One Microsoft Way, Redmond, Washington 98052, United States of America, The following specification particularly describes the invention arid "the manner in which it is to be performed: WO 01/98926 PCT/USO1/15223 NETWORK-BASED SOFTWARE EXTENSIONS TECHNICAL FIELD This invention relates to methods and systems for providing software via a network. More specifically, the invention pertains to Internet-based delivery of software. BACKGROUND OF THE INVENTION Installation of traditional PC applications requires physical media, such as a disk or CD-ROM that must be physically inserted into a computer in order for software to be loaded onto a user's computer. Typically, this process requires the user to enter settings information that can be confusing to the user. Once the software is installed, it is typically fixed in terms of its location and functionality. When the software is updated, the user must typically purchase additional physical media and repeat the installation process so that they can use the updated software. In this model, the software is fixed in its association with the computer on which it was installed. If a user moves to another conrputer, they will not be able to use the specific software on their machine without repeating the installation process. As computing continues to evolve into the environment of computer networks such as the Internet, it has become clear that the traditional software delivery model described above is inadequate to meet the demands of consumers who desire dynamic, flexible, and adaptable software on-demand. Network-based software delivery is becoming the subject of increasing focus by those who develop and deliver software. Unlocking the potential for network-based software delivery WO 01/98926 PCT/OS01/15223 2 will require smart, innovative and streamlined solutions, especially in situations where bandwidth may be limited. Accordingly; this invention arose out of concerns associated with providing new software delivery models that are particularly well-suited for network-based 5 software delivery, e.g. delivery via the Internet. SUMMARY OF THE INVENTION Methods and systems for network-based software delivery are described. In one embodiment, an application program or software platform resides on a client 10 The program or platform is configured so that it is extensible based on software extensions that are deliverable over a network such as the Internet Various extensions can be developed by third party developers for incorporation into the program or platform. In one described embodiment, extension files that comprise a software 15 extension are hosted on a network server such as an Internet server. These include descriptor files that describe aspects of the software extension. These descriptor files logically describe an extension to the program or platform and designate the location of other extension files. Extensions are incorporated on a client by navigating to a particular network or Internet site through which the extensions can 20 be accessed. The files describing the extension files are downloaded on the client These tiles tell the client where, when and how the particular extension can be plugged into the program or platform, as well as where to find the appropriate extension files and how to download them. The extension files are then downloaded and incorporated into the platform. 25 In one embodiment, an inventive software architecture is provided for handling and consolidating particular types of descriptive files associated with WO 01/98926 PCT/USO1/15223 3 various extensions. A filtering mechanism called attachment points, is used to create handlers for the different descriptive types of files that define a software extension. Each of these handlers is known as an attachment manager. Attachment managers are provided for each extensible feature type. The attachment managers 5 interpret data from extensions files which are supplied by attachment points. In addition to predefined attachment managers, custom attachment managers can be created using data from attachment points. When an extension extends a particular feature type, the attachment points ensure that only the appropriate attachment manager is notified so that the feature type can be incorporated into the program or 10 platform efficiently. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a high level view of a system that can be utilized in accordance with one described embodiment. 15 Fig. 2 is an exemplary computer system mat can be utilized in accordance with the described embodiment Fig. 3 is a diagram of an exemplary EDF and PKG in accordance with one described embodiment Fig. 4 shows a portion of an EDF in accordance with the described 20 embodiment Fig. 5 shows a portion of an EDF schema in accordance with the described embodiment Fig. 6 shows a portion of a PKG in accordance with the described embodiment 25 Fig. 7 is a block diagram illustrating how file hashes can be used for versioning in accordance with one embodiment WO 01/98926 PCT/US01/15223 4 Fig. 8 is a block diagram that illustrates two exemplary package objects in accordance with one embodiment. Fig. 9 is a flow diagram that describes steps in a method in accordance with one described embodiment 5 Fig. 10 is a flow diagram that describes steps in a method in accordance with one described embodiment Fig. 11 is a block diagram that illustrates an exemplary package manifest !. creation-tool in accordance with one described embodiment. Fig. 12 is a flow diagram that describes steps in a method in accordance with 10 one described embodiment. Fig. 13 is a flow diagram that describes steps in a method in accordance with one described embodiment Fig. 14 is a flow diagram of steps in a method in accordance with the described embodiment 15 Fig. 15 is a flow diagram of steps in a method in accordance with the described embodiment Fig. 16 shows a portion of an exemplary catalog structure in accordance with the described embodiment Fig. 17 is a block diagram of a software architecture in accordance with the 20 described embodiment Fig. 18 is a flow diagram of steps in a method in accordance with the described embodiment Fig. 19 is a diagram that illustrates one aspect of attachment point architecture in accordance with the described embodiment. 25 Fig. 20 is a diagram that illustrates one aspect of the Fig. 17 architecture. WO 01/98926 PCT/US01/15223 5 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Overview The methods and systems described just below provide a mechanism by which functionality can be added dynamically to an application program or 5 software platform. Functionalities or "extensions" as they will be referred to, can be advantageously added via a network such as the Internet. Extensions, mat can implement new features or add to existing features, can be added using only a network address, such as a URL, as a basis for extension installation. That is, all of the files that comprise an extension can be maintained on the network and accessed 10 via one or more network sites. Extensions can be described in a variety of ways. One way utilizes a hierarchical tag-based language which facilitates handling and use of the various extensions. In one particular implementation, a software platform is provided that can incorporate various functionalities. The software platform and the inventive 15 architecture described below enable third and fourth party developers to develop extensions for the platform that can be easily and seamlessly incorporated into the platform without having any knowledge of (or relationship with) a hosting service. A third party developer is a developer who develops an extension for the platform. A fourth party developer might be a developer who develops an extension to a third 20 party developer's extension. Tnus, the incorporation of third and fourth party extensions is essentially a transparent process, as far as developers are concerned. Consider for example, Fig. 1 which shows a user's computer 100 and several so-called extension sources 102,104, and 106. The extension sources can comprise any entity from which a software extension can be obtained via a network In an 25 exemplary implementation, the network can comprise the Internet, although other networks (e.g. LANs and WANs) can certainly be utilized. Extension sources can WO 01/98926 PCT/US01/15223 6 include, without limitation, business entities such as retail stores that might rriaintain a network site. In one implementation, a user can execute software on their computer that provides an application program or software platform. In this document, the terms "application program" and "software platform" will be used interchangeably. Each of the different extension sources 102-106 can provide software extensions that can plug into the software platform that is executing on the user's machine. These extensions are deliverable via a network such as the Internet, and assist in providing applications that can be executed on the user's machine. In the described embodiment, the extensions are logically described in XML which is 10 in line with emerging industry standards. Additionally, the use of XML assists in the future discoverability of extensions by promoting XML DOM properties on the Internet. It will be appreciated, however, that any suitable format can be used for describing the extensions, e.g. a binary description could be used. Extensions can be delivered from any number of different extension sources. The inventive methods and systems provide a streamlined and organized way to handle the provided extensions. The use of XML advantageously enables efficient handling of extensions from multiple different extension sources, without unduly taxing the software components that utilize specific portions of an extension or extensions. In one particular implementation, the software platform on the user's machine provides various different integrated functionalities that enable a user to accomplish different document-centric tasks. An exemplary system is described in the U.S. Patent Application entitled "Single Window Navigation Methods and Systems", incorporated by reference above. WO 01/98926 PCT/US01/15223 7 Exemplary Computer Environment The embodiment described just below can be employed in connection with various computer systems. A computer system, for purposes of mis document, can be considered as any computing device that includes some type of processor, i.e. a 5 microprocessor, and some type of operating system. Thus, a computer system can be construed to include, without limitation, traditional desktop computers, more powerful servers, various hand-held devices such as cell phones, pocket-held computer devices and the like. Fig. 2 shows but one exemplary computer system that can be used to 10 implement the embodiments described herein. Computer 130 includes one or more processors or processing units 132, a system memory 134, and a bus 136 that r ' couples various system components including the system memory 134 to processors 132. The bus 136 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated 15 graphics port, and a processor or local bus using any of a variety of bus architectures. The system memory 134 includes read only memory (ROM) 138 and random access memory (RAM) 140. A basic input/output system (BIOS) 142, containing the basic routines that help to transfer information between elements within computer 130, such as during start-up, is stored in ROM 138. 20 Computer 130 further includes a hard disk drive 144 for reading from and writing to a hard disk (not shown), a magnetic disk drive 146 for reading from and writing to a removable magnetic disk 148, and an optical disk drive 150 for reading from or writing to a removable optical disk 152 such as a CD ROM or other optical media. The hard disk drive 144, magnetic disk drive 146, and optical disk drive 25 150 are connected to me bus 136 by an SCSI interface 154 or some other appropriate interface. The drives and their associated computer-readable media WO 01/98926 PCT/US01/15223 8 provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for computer 130. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 148 and a removable optical disk 152, it should be appreciated by those skilled in the art 5 that other types of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROMs), and the like, may also be used in the exemplary operating environment A number of program modules may be stored on the hard disk 144, magnetic 10 disk 148, optical disk 152, ROM 138, or RAM 140, including an operating system 158, one or more application programs 160, other program modules 162, and program data 164. A user may enter commands and information into computer 130 through input devices such as a keyboard 166 and a pointing device 168. Other input devices (not shown) may include a microphone, joystick, game pad, satellite 15 dish, scanner, or the like. These and other input devices are connected to the processing unit 132 through an interface 170 that is coupled to the bus 136. A monitor 172 or other type of display device is also connected to the bus 136 via an interface, such as a video adapter 174. In addition to the monitor, personal computers typically include other peripheral output devices (not shown) such as 20 speakers and printers. Computer 130 commonly operates in a networked environment using logical connections to one or more remote computers, such as a remote computer 176. The remote computer 176 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes 25 many or all of the elements described above relative to computer 130, although only a memory storage device 178 has been illustrated in Fig. 2. The logical connections WO 01/98926 PCT/USO1/15223 9 depicted in Fig. 2 include a local area network (LAN) 180 and a wide area network (WAN) 182. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When used in a LAN networking environment, computer 130 is connected to 5 the local network 180 through a network interface or adapter 184. When used in a WAN networking environment, computer 130 typically includes a modem 186 or other means for establishing communications over the wide area network 182, such as the Internet;. The modem 186, which may be internal or external, is connected to me bus 136 via a serial port interlace 156. In a networked environment, program 10 modules depicted relative to the personal computer 130, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. Generally, the data processors of computer 130 are programmed by means of 15 instructions stored at different times in the various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy disks or CD-ROMs. From there, they are installed or loaded into the secondary memory of a computer. At execution, they are loaded at least partially into the computer's primary electronic memory. The invention described 20 herein includes these and other various types of computer-readable storage media when such media contain instructions or programs for implementing the steps described below in conjunction with a microprocessor or other data processor. The invention also includes the computer itself when programmed according to the methods and techniques described below. 25 For purposes of illustration, programs and other executable program components such as the operating system are illustrated herein as discrete blocks, WO 01/98926 PCT/USO1/15223 10 although it is recognized mat such programs and components reside at various times in different storage components of the computer;, and are executed by the data processors) of the computer. Extensions An "extension", as used in this document, will be considered to include, without limitation, software functionality and content that can be added to an application program or software platform. These additions typically provide some type of functionality that the application program may not have had before the extension was incorporated, or alter the behavior of at least one existing feature. The extension is incorporated or integrated directly into the application program in a way that changes, to some degree, the manner in which the application program behaves or operates. Extensions provide dynamically added content and can provide applications (such as an email application), plug-ins to extend existing applications (like a fax plug-in to an email application), or simply web pages, to name just a few. In the described embodiment, extensions are described using XML, an industry-standard, text-based markup language. XML greatly facilitates the extensibility of software content. Specifically, various extensions can be authored by third parties and described in XML in a manner that enables the extensions to be readily integrated into application programs. It should be appreciated, however, the XML constitutes but one exemplary way of describing and using the extensions. Other ways can, of course, be used. WO 01/98926 PCT/CS01/15223 11 Exemplary Extension Organization In the described embodiment, extensions are organized in three separate but related portions: an Extension Definition File (EDF), a Package Manifest (PKG), and the code, components, or "bits" that make up or define the extension. An EDF 5 can be, but need not be associated with a URL (Universal Resource Locator) that provides a way for a client to access the EDF. By convention and choice, the PKG file is located at the same URL as the EDF. It will be appreciated that the described EDFs and PKG are each not required for the other to be used. It just so happens that, in the example that is given is this document, the two are employed together. 10 To that end, each of these features can be separately and independently employed. EDFs describe logical attachments to an application program or software platform, while PKGs specify the physical files and resources that are used in an extension. There can be a one to one correspondence between EDFs and PKGs. Fig. 3 shows an exemplary organization 300 that includes an EDF 302 and a 15 corresponding package manifest (PKG) 304. In the illustrated example, the EDF 302 uses XML to describe the logical attachments or extensions to an application program. The corresponding PKG 304 specifies the physical files and resources that are associated with a particular extension. Exemplary file types are shown to the right of PKG 304 and include, without limitation, HTM, GIF, UDO, XML, 20 DLL, and various other types of files. Extension Definition File (EOF) In the described example, an EDF is an XML file mat logically describes an extension. For example, the EDF can describe HTML that makes up a user 25 interface (UI), the objects that contain code for implementing various functions, and the like. The EDF can also contain all or part of the functionality that comprises an WO 01/98926 PCT/CS01/15223 12 extension. For instance, the HTML that describes a toolbar could be incorporated directly into an EDF file, and a toolbar attachment manager could read it from the EDF file, instead of from a URL. The information contained in the EDF is processed and (together with the information contained in the PKG), the 5 appropriate files are automatically installed on a user's computer. This is done unobtrusively without manipulating die computer's persisted settings, as might be found in the user's system registry. An EDF, implemented in XML, contains various tags that are associated . with various extensions. The various tags can correspond to: 10 User interface elements Behaviors/Components/Obj ects Store Elements User-defined objects Or anything else that represents a point of extensibility in the application or platform 15 EDFs advantageously have an "open schema" which means that third party developers can extend the extension mechanism and include their own extensions 20 by creating their own tags. Additionally, extensions can themselves be extended by other developers. EDFs can also have one or more predefined tags. Exemplary predefined XML tags for user interface elements can include tags for feature types such as: tool bars, accelerators, menu items, and themes. These feature types are utilized in the single navigable window application incorporated by reference above 25 and defined in the table immediately below: WO 01/98926 13 Feature Type Definition Tool Bars Horizontal command containers above the document area. Accelerators Keyboard shortcuts for commands Menu Items Pop-up or drop-down menu choices that third parties can add to well-known, named menu attachments in the platform Themes A data-driven way to provide overrides fox well-known resources of the platform, such as default buttons or default style sheet Table 1 Exemplary predefined XML tags for behaviors/components/objects include tags for Services. These feature types are utilized in the single navigable window application incorporated by reference above and defined in the table immediately below: Feature Type Definition Services Services are objects that extend existing objects (such as the application, window, or document) in the application or platform's Object Model. For example, editing functions use Object Model Attachments attached to the window or document mat maintain document context and editing state per-window. These can also include Object Model Attachments attached to the application (such as a spellchecker dictionary object) Table 2 Exemplary predefined XML tags for store elements include tags for content classes and off Fine data sources. These feature types are utilized in the single navigable window application incorporated by reference above and defined in the table immediately below: WO 01/98926 PCT/US01/15223 14 Feature Type Definition Content Classes Allow extension writers to define new types of XML documents with new schemas. Offline Data Sources Allow for extension writers to define store replication instructions in an EDR Table 3 EDF Schema In the described embodiment, the EDFs have a particular XML schema that 5 is utilized. The schema comprises collections of XML tags that are arranged in a hierarchical organization to facilitate information dissemination to software components that need certain extensions. In the described embodiment, the outer (encompassing tag) for EDFs is an "extension" tag. Fig. 4 shows an exemplary extension tag. "extension" tags can include one 10 or more of the following attributes, all of which are optional: Attribute Definition Urn ID for the extension. It allows extension writers to specify relative locations for content in EDFs without using relative paths or fixed URLs. It also allows hosting administrators to move around extensions on servers without breaking any links. Name Name that can be used in a status bar or message display Version Vendor-determined version number for the extension. last Update Date/time that the EDF was last modified. description Brief description of the extension. Table 4 Within the "extension" outer tag are one or more child tags, also referred to 15 as 'top level tags". These top level tags are each associated with a feature type that can be added by a particular extension. Exemplary feature types are discussed in WO 01/98926 PCT/US01/15223 15 connection with Tables 1-3 above. Underneath each top level tag there can be one or more child tags that are individually associated with a particular feature of the feature type that is to be added by a particular extension. Fig. 5 shows an exemplary XML schema organization in accordance with 5 this embodiment For each top level tag in an EDF, there is an associated attachment manager which is a software component that receives data associated with the tag so that the data can be used to incorporate the extension into the platform or application program. Different attachment managers may interpret the data from the tag in different ways to provide different types of extensibility, so 10 different top level tags will contain different types of data in different structures. This will become more evident in the "Architecture" section below. Note that the "edf:" XML namespace qualifier enables support of an open schema where extensions can provide their own tags and corresponding attachment managers. Tags within the edf namespace are used by built-in attachment managers in the 15 application or software platform. Tags in other namespaces are used by third-parties to provide additional points of extensibility. Package Manifest (PKG file) The package manifests (PKGs) assist in organizing the downloading of 20 software in the form of multiple files over a network such as the Internet The PKGs are advantageously employed, in the example given in this document, with EDFs. As pointed out above, however, the techniques discussed in connection with the PKGs can he deployed independently of EDFs and in any suitable scenario where it is desirable to deliver software over a network such as the Internet While 25 the EDFs describe the logical attachment of extensions into an application program or platform, the package manifest's role is to assist in one or more of: organized WO 01/98926 PCT/USO1/15223 16 delivery, validation and/or, updating of files associated with the various extensions that can be provided. In designing a delivery mechanism for Web-assisted delivery of software content or files, several considerations are of interest. 5 Whenever possible, it is desirable to reduce the size of required downloads during update and installation operations. To address this consideration, software content is broken into multiple packages. Each package contains a group of one or more files that implement a common or well-defined functionality. By breaking the content into individual packages, the size of the required download during 10 installation and update can be minimized. Each package is then described by a package manifest (PKG) that includes file information such as file locations and hash values mat can be used for validation or security and versioning. It is also desirable to give the end user a Web-like experience. To do this, extensions are loaded in a manner that feels to a user more like they are loading a 15 web page, rather than traditional software packages where the user has to wait until the entire package is loaded before they can interact with it In the described embodiment, users are given a web-like experience by streaming the extension files down to the client so that a user can begin to interact with an application program much sooner than if they had to watt for the entire software application program to 20 load. For example, if mere are user interface (UQ image files streaming down, the user can see the UI as the files stream in. Consider, for example, the single application program having the multiple different functionalities that is described in the patent application incorporated by reference above. A user might browse to an email functionality and download the files that are necessary to interact with the 25 email functionality. Files that are associated with another different functionality would then be downloaded after the files associated with the email functionality. In WO 01/98926 PCT/US01/15223 17 this way, the user can begin to operate within a particular functionality without having to wait for all of the files associated with all of the other functionalities. Another consideration of interest pertains to the efficiency with which the extension files or "bits" are delivered to the client. To address this consideration, 5 the described embodiment utilizes a couple of different download approaches: a throttled download and a background download. Throttled downloading conducts download operations while taking into account the available bandwidth and type of media over which the files are being transferred [ Any suitable throttled download process can be employed and will be understood by those of skill in the art 10 Background download is conducted while the user is working wimin the application program and is implemented by allocating a background thread so that the user can continue their work. One optimization that is utilized is that packages are prioritized and delivered in accordance with what a user might be working on. Another consideration is associated with optimizing the user's computing 15 experience. Here, the user's experience is optimized by making available the most common scenarios foT the user. This is effectively directed to giving the user the functionality that they want first, and then, through the background download process, providing the code that implements functionalities that the user might use in the future. To determine which functionalities a user desires to have first, an 20 automated scenario-based packaging process is provided that runs against file usage logs from scripted scenarios. All of these considerations and the inventive solutions directed to addressing the considerations are discussed in detail in the sections that follow below. WO 01/98926 PCT/OS01/15223 18 Package Manifest Definition In the described embodiment, a package manifest (PKG file) comprises a list of files that are utilized in a package. The list is advantageously compressed somewhat and digitally signed. Each package manifest can contain a list of one or 5 more files each of which can include an associated hash, as well as download directives that control caching of the flies. Once an extension is authored, a software tool can be used to generate the package manifest In addition, the package manifest can specify several other pieces of information: 10 FILE GROUP All files in an extension can be labeled according to a number of predefined file groups. The file group of a particular file determines when the particular file gets downloaded, where it is stored on the client, and how it gets packaged. In the 15 described embodiment, four predefined file groups are provided and are listed and described in the table immediately below: Group name When downloaded Where stored on the client Packaging Content Required Downloaded before any other files in the extension. NetDocs package cache AII required files in an extension are packaged together as a CAB*» file. DLLs included so that a user will not have to wait for a prolonged period of time before clicking on a UI element Offline Offline files start getting downloaded as soon as Required are down. Providing the user stays on line long enough, these files will all get downloaded and will later be available for offline use. NetDocs package cache File are sent down individually. Bulk oftheUI files. On demand Only downloaded when | NetDocs Files are sent lb avoid using up disk WO 01/98926 PCT/US0l/15223 19 they are requested for the first time. package cache down individually. space on the client, advanced features can be pat in this category. Online only Downloaded on demand. Content is only available when the user is online. WinInet Cache Files are sent down individually Content that is not to be provided offline. Examples include help pages and other content that can consume a large amount of disk space. * CAB stands for the CABinet technology that Internet Explorer uses to package bits for download CAB files average from 2 to 3:1 compression, and are optimized for quick expansion. CAB files have the added security benefit that they are easily signed. WO 01/98926 PCT/US015223 20 • FILE DOWNLOAD PRIORITY Files in each group are listed according to the order in which they should be downloaded. This download order is implicit in the ordering of the files in the 5 package manifest, an example of which is shown in Fig. 6. • HASH VALUE FOR SECURITY/VERSIONING Individual files in the package manifest can have an associated hash value. Each hash value is generated by running the file through an encryption algorithm. 10 An exemplary encryption algorithm is Microsoft's CryptoAPL In the illustrated example, each file can be listed with a base 64-encoded hash value, so that the file can be validated once the content arrives at the client Specifically the package manifest is sent to the client in a secure manner (i.e. it is digitally signed). The package manifest contains the hash values for individual files. When the individual 15 files are received by the client, each of the files can be run through the same Crypto API that was used to provide the hash values in the package manifest. If the hash values for a particular file compare favorably, then the file has not been altered and is secure. When a file is updated, hash values can serve a useful purpose in identifying 20 files that have not been changed between different versions of an extension. Consider Fig. 7, for example. There, an old directory 700 in a client package cache contains package A which include two files—file 1 with hash = x, and file 2 with hash = y. Assume that this package is associated with an older version of an extension. When an updated version is produced, its package manifest is delivered 25 to the client. The updated extension version is represented on a source directory of a code or web server 704. The package manifest includes the hash values for all of WO 01/98926 PCT/US01/15223 21 the files in the new extension version. A new client destination directory 702 is defined for all of the files of the new extension. If any of the hash values for files in the new extension are the same as the hash values of the files in the old directory 700, then those files can be copied directly from the old directory 700 to the new 5 destination directory 702. hi this example, file l's hash value is the same as the hash value for file 1 on the source directory 704, so it can be copied into the new destination directory 702. File 2's hash value, however is different from the hash value for^ file 2 on the source directory, so it is not copied from the old directory 700. Rather, file 2 is downloaded from the code server. A new file 3 has been 10 added and is also downloaded from the code server. Hence, in this example, a new version of an extension resulted in a download of less than all of the files in the extension [version. This is because hash values for each of the files in the old extension, version were able to be compared with hash values of the files in the new extension version. Those hash values that are the same indicate files that have not 15 changed as between versions. Using hash values for versioning has two important advantages over traditional versioning schemes. First, the update process is automatic. That is, with an explicit version number, it is possible to forget to update the version number when shipping a new release of a file. Using hash values avoids this problem, 20 Second, versioning does not rely on file types. Specifically, traditional versioning schemes commonly embed version information within files; however, not all files (e.g. GIF files) support embedded version information. In the- present example, using hash values for versioning does not depend on whether a particular file type supports or does not support embedded version information. In addition, the 25 version infonnation can be stored separately from the file itself. Thus, access to actual file to determine whether it is current is not needed WO 01/98926 PCT/CS01/15223 22 • TOTAL STORAGE SIZE OF PACKAGE The total storage size of a package is useful at download time to verify that the user has sufficient disk space. 5 • ClassID's FOR THE DLLs Listing ClassIDs for each DLL is necessary to enable script writers to create classes by scripting against the OM. Additionally, this enables a determination of which package contains the code for a particular class. 10 • DLL LOAD DEPENDENCIES The reason for the dependencies section is to allow for legacy code that relies on being loaded by virtue of being in the search path of some other dll. In this 15 case we have to make sure that the dependency dll is in the package cache directory before the dependant dll is loaded. Fig. 6 shows an exemplary package manifest 600 that is defined in a hierarchical tag-based language. Advantageously the tag-based language comprises XML which is desirably extensible and flexible. In this example, a number of tags are provided in a hierarchical arrangement. The 20 “package” tag contains information about the size of the package. The "files" tag is a child of the package" tag and contains information about the file groups that are contained in that particular package. The "file" tag is a child of the "group" tag and contains information about specific files that comprise the extension, i.e. file name and hash value. A "dependency" tag is provided as a child of the "file" tag and lists 25 any dependencies as discussed above. A "COMClass" tag is also provided as a WO 01/98926 PCT/US01/15223 23 child of the "file" tag and contains IDs as mentioned above. The ordering of the file groups in. this schema implicitly defines the download order of the files. Package Delivery 5 To optimize package delivery, two different delivery schemes are utilized. First, a throttled download approach is utilized using known throttling download techniques. Here, considerations such as available bandwidth and media over which the extensions are being provided are considered. Second, a background download approach is utilized. Background 10 downloads enable a user to continue to work within an application program while content is downloaded. Foreground downloads are used when the user has explicitly requested a file/extension by clicking, for example, on an extension link, or requested an action, for example, by clicking on the "Compose" mail button, that requires download of files which are not available locally. 15 Along with background downloads, a queue management feature is provided. Specifically, when an extension must be installed or updated, a package manager, which is essentially a software component that manages packages, is provided with the following information: 20 • URL for the package manifest information on a code server • URN for package destination directory in the package cache at the client • (Optional) URN for the old package directory (if one exists) in the package cache From this information, the package manager creates a package object and 25 adds the package object to a download queue. The download queue is designed for easy rearrangement of a package download order. Consider, for example, Fig. 8 which shows a portion of a download queue 800 that contains two package WO 01/98926 PCT/USO1/15223 24 objects—package object 802 (corresponding to package A) and package object 804 (corresponding to package B). The package objects maintain a list of which files of a corresponding package have been downloaded or installed. In the present example, files 1 and 2 from package A have been installed while file 3 has not been 5 installed; and files 1, 2, and 3 have not been installed from package B. The download queue can be rearranged based on what the user is doing. That is, based on the actions that a user takes, the priority of files that are to be downloaded can be changed. In this example, the package manager is designed to process the first uninstalled file in the package at the head of the download queue. If, however, the 10 user starts to use a file in an extension that is different from the extension whose files are at the head of the download queue, the corresponding package for the file that the user has started to use can be moved to the head of the download queue. Because a file's package is specified by its URN, the filers package can be quickly identified and located in the download queue. For example, and considering Fig. 8, 15 if one of the files in package B is requested before the package manager has started to install package A's third file, then package B will be moved to the head of the download queue. Fig. 9 is a flow diagram that describes steps in a download queue management method in accordance with the described example. The method can be 20 implemented in any suitable hardware, software, firmware or combination thereof. In the present example, the method is implemented in software. Step 900 receives one or more requests for an extension. The requests can be generated in any suitable way. Step 902 creates a package object that corresponds to each extension package that is to be downloaded. Step 904 arranges 25 the package objects in a download queue. Step 906 men downloads files corresponding to the package objects in the download queue. This step can be WO 01/98926 PCT/US01/15223 25 implemented by, for example, starting at the head of the download queue and downloading files until all of the tales for a package object have been downloaded, and then moving to the next package object. Step 908 ascertains whether a user action requires a file that is not described in the current package object. If the 5 user's action does not require a rile not described by the current package object, then the method branches back to step 906 and continues to download files associated with the current package object. If, on the other hand, the user's action requires a files that is not described in the current package object, then step 910 moves the package object associated with the required file to the head of the 10 download queue and begins to download files associated with this newly-repositioned package object This step can be implemented by ascertaining which package object is associated with the required file by ascertaining the URN associated with the file. This URN specifies the file's package so that its package object can be quickly located and moved to the front of the download queue. 15 Package Creation One of the innovative features of the described embodiment is its extensibility. That is, a software platform is provided in the form of an application program that can be extended by various tried-party user-defined extensions. These 20 extensions are delivered via the Web and are integrated directly into the software platform. In order to provide an organized delivery process, packages should be created in a uniform manner so that they can be predictably handled and integrated into the software platform. In accordance with the described embodiment, each package should 25 correspond to an end-user feature. For example, in the patent application incorporated by reference above, separate packages are provided for each of the WO 01/98926 PCT/USO1/15223 26 email, contacts, document authoring, and planner functionalities. If packages that do not depend on one another share a dependency, then mis shared dependency should become its own package. For example, mere is no reason why the email and document authoring functionalities should depend on one another, yet both of them 5 require the ability to publish content By separating the publishing functionality into its own package, a certain amount of download order flexibility is preserved. Depending on what the user starts to work on, the files corresponding to the email functionality or the document authoring can be downloaded first. Fig. 10 is a flow diagram that describes steps in a package creation method 10 in accordance with the described example. The method can be implemented in any suitable hardware, software, firmware or combination thereof. Portions of the method might, however, be implemented manually. Step 1000 identifies end user features that are to be provided as extensions. Step 1002 identifies any shared dependencies among the end user features. Step 15 1004 creates individual packages for the end user features. Step 1006 creates individual packages for any shared dependencies among the end user features. Automated Package Manifest Creation Tool Advantageously, and in accordance with one implementation, an automated 20 package manifest tool is provided and takes various input parameters and automatically creates a package manifest. The tool can be available to third parties to assist them in creating a package manifest. Fig. 11 shows an exemplary package manifest creation tool 1100 that is desirably implemented in software. In this specific example, me tool can take the 25 following input parameters (some of which are optional): WO 01/98926 PCT/US01/15223 27 • Extension directory • File group information and DLL load dependencies (Optional) • File usage statistics from scenario runs (Optional) 5 The extension directory input parameter specifies the directory containing all of the files that will he described by the package manifest If this is the only parameter, then tool 1100 will generate a manifest in which the EDF and DLLs in the directory are listed in the "Required" set, and all other content is "Offline". The file group information and load dependencies parameter is optional. If 10 an extension author has an idea of the categories in which his or her files should be placed, the categories should be specified here. For example, the author of the r template manifest shown below knows that he wants his error handling GIF to be included in the package's required set His choices here will always be respected in the final manifest. Additionally, if the extension author knows of any DLL load 15 dependencies, these should be specified here as well. 20 25 20 ". Explode attachment point 1902 takes as an input 25 attachment point 1900 and exposes a list of XML nodes which are children of source XML nodes. In this example, the list of XML nodes exposed by attachment WO 01/98926 PCT/CS01/15223 45 point 1902 are the "" nodes and the "M nodes. The filter attachment point 1904 takes attachment point 1902 as an input and filters on "menus." It then exposes an XML list having only "" nodes in it The explode attachment point 1906 takes attachment point 1904 as an input and exposes 5 a list with the XML nodes that are contained in the "" nodes—here both of the "M nodes. Consider additionally mat the toolbar attachment manager would request a predicate chain of attachment points which would also use URL attachment point, an Explode attachment point and a filter attachment point 1904 that filters on 10 'toolbars". Thus, the corresponding explode attachment point 1906 would expose an XML list containing only the "w node. But, the attachment point manager would detect the commonality of the URL attachment point and the inner Explode attachment point, so it would reuse the same attachment points it created for the menu attachment manager. The Filter attachment points used by tile toolbar 15 attachment manager and the menu attachment manager would use the same Explode attachment point as their data sources but would expose different collections of nodes, because they were filtering based on different criteria. Consider Fig. 20 which incorporates an EDFHub attachment point 2000. This attachment point receives all of the EDFs and, as discussed above, combines 20 mem into a single XML list. The EDFHub then exposes the root nodes of all of the EDFs. The explode attachment point 2002 then exposes an XML list that contains all of the top level nodes for all of the EDFs. As an example, there may be multiple EDFs that each contain top level menu nodes, toolbar nodes, accelerator nodes and the like. Explode attachment point 2002 exposes an XML list mat contains all of 25 these top level nodes for all of the EDFs. Filter attachment point 2004 can then filter the XML list exposed by the explode attachment point 2002 in accordance WO 01/98926 PCF/USOl/15223 46 with any suitable parameters (i.e. filter on menu nodes, tool bar nodes, accelerator nodes and the like). the final explode attachment point 2006 then exposes a list of the individual children nodes of the list exposed by the filter attachment point 2004. This list describes all of the specific features (of the particular type that were 5 filtered) that have been added by all of the EDFs. The table below lists a number of different attachment points that can be utilized in accordance with this described embodiment but many more can easily be created. Attachment Point Purpose URL Loads the URL and exposes the top level XML node as a member of the collection Context For every member, it gets the "expression" attribute and binds to it. If the expression evaluates to true, then the member is exposed. EDF Same as the URL AP, but also exposes a fabricated member with data to create an APP based on the URL and URN (which exists in the XML DOM). Merge Takes zero or more Attachment Points (of any type) and merges them together. The order and continuity of the original collections will be maintained. Filter Monitors a single Attachment Point and only exposes those nodes that match the specified name. The order of the original collection will be maintained. Duplicate Monitors a single Attachment Point and filters out any duplicates. A duplicate is defined to be having the same URN attribute. If no URN attribute is present then the node is exposed. Order of the original collection will be maintained. Explode Monitors a single Attachment Point and for every member exposes the children WO 01/98926 PCT/US01/15223 47 of that member as its members. The order of the original collection will be maintained as well as the order of the children within the nodes. Link Monitors a single Attachment Point and for every member looks for a URL attribute and creates a URL AP and merges it into itself. If the optional include Content is set to true, it will merge the original collection in as well. Link Monitors a single Attachment Point and for every member looks for a URL attribute and creates a URL AP and merges it into itself. If the optional include Content is set to true, it will merge the original collection in as well. Order Monitors a single Attachment Point. For every member, it gets three attributes: id, before and after. Based on this information, it reorders the members as specified. If no ordering information is supplied, the order of the original collection will be maintained. EDFHub This Attachment Point is the central merge point that represents all the EDF points. Conclusion The embodiments described above provide a platform solution that provides for customization and extensibihty through a consistent and logical extensibility mechanism and object model mat can be easily understood by third party developers. Internet-based downloads can be accomplished without a great deal of user intervention and without manipulating any user persisted settings. Extensions can be provided to a software platform or application program dynamically based upon the user's computing context. Although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention WO 01/98926 PCT/USO1/15223 5 48 defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are disclosed as preferred forms of implementing the claimed invention. We Claim: 1. A data structure embodied on a computer-readable medium comprising: a first sub-structure indicative of a software extension that is to be incorporated in a software application program; one or more second sub-structures associated with the first sub-structure and indicative of feature types that can be added by the extension to the application program; and one or more third sub-structures associated with the one or more second sub-structures and indicative of features of an associated feature type that can be added by the extension. 2. The data structure as claimed in claim 1, wherein the one or more second sub-structures are children of the first sub-structures. 3. The data structure as claimed in claim 1, wherein the one or more third sub-structures are children of the one or more second substructures. 4. The data structure as claimed in claim 1, wherein the one or more second sub-structures are children of the first sub-structures, and the one or more third sub-structures are children of the one or more second sub-structures. 5. The data structure as claimed in claim 1, wherein the substructures comprise XML tags. 6. The data structure as claimed in claim 1, wherein the feature types comprise one or more of the following feature types: user interface elements; behaviors, components, or objects; store elements; and user-defined elements. 7. The data structure as claimed in claim 1, wherein the data structure comprises an open XML schema that can be extended. 8. The data structure of claim 1, wherein the data structure comprises an open XML schema that can be extended by third parties. Dated this the 27th day of February, 2006