Network-based software extensions

[0001] (Technical field) The present invention relates to methods and systems for providing software over a network. More specifically, the present invention relates to Internet-based software distribution. [0002] (Background of invention) To install a traditional PC application, you need a physical medium, such as an optical disc or CD-ROM, to load the software onto your computer, which you must actually insert into your computer. Normally, this process requires the user to enter setting information, which is a difficult task for the user to understand. Once the software is installed, it is usually fixed in terms of location and functionality. When updating software, users typically have to purchase additional physical media and repeat the installation process before they can use the updated software. In this model, the software is fixed in relation to the computer on which it is installed. If a user moves to another computer, they will not be able to use certain software on that machine without repeating the installation process. [0003] As computing evolves into computer network environments such as the Internet, the traditional software distribution model described above is inadequate to meet the needs of consumers who desire flexible, adaptable and dynamic software on demand. It has become clear that there is. Network-based software distribution has been of great interest to those who develop and distribute software. Unleashing the potential of network-based software distribution requires sophisticated, innovative and streamlined solutions, especially in situations where bandwidth is limited. [0004] Therefore, the present invention has arisen from interests specifically related to providing new software distribution models that are most suitable for network-based software distribution, such as distribution over the Internet. [0005] (Summary of invention) Describe methods and systems for network-based software distribution. In one embodiment, the application program or software platform is placed on the client. This program or platform is configured to be extensible based on software extensions that can be distributed over networks such as the Internet. Third-party developers can develop various extensions to embed in programs or platforms. [0006] In one embodiment described, the extension file containing the software extension is hosted on a network server such as an internet server. These extension files include descriptor files that describe aspects of software extensions. This descriptor file logically describes a program or platform extension and specifies the storage location for other extension files. The extension is built into the client by navigating to a specific network or internet site that can be used to access the extension. The file that describes the extension file is downloaded on the client. These files tell the client where to plug in a particular extension into a program or platform, when and how to do it, where the appropriate extension files are located, and how to download them. Download the extension file and incorporate it into the platform. [0007] In one embodiment, the software architecture of the present invention is provided for processing and organizing certain types of descriptive files associated with various extensions. Use a filtering mechanism called attachment points to create handlers for various descriptive files that define software extensions. Each handler is called an attachment manager. An attachment manager is provided for each expandable function type. The attachment manager interprets the data in the extension file provided by the attachment point. In addition to the predefined attachment managers, you can create custom attachment managers using data from attachment points. When an extension extends a particular feature type, this attachment point ensures that only the appropriate attachment manager is notified and that feature type can be efficiently incorporated into the program or platform. [0008] (Detailed description of preferred embodiments) Overview The methods and systems described below provide a mechanism for dynamically adding functionality to an application program or software platform. As the name implies, an extension, or "extension," is advantageous to add over a network such as the Internet. Extensions for implementing new features or adding to existing features can be added using only network addresses such as URLs as the basis for installing extensions. That is, all files containing extensions can be kept on the network and accessed through one or more network sites. [0009] Extensions can be described in various ways. One method utilizes a hierarchical tag-enabled language that simplifies the processing and use of various extensions. In one specific embodiment, a software platform that can incorporate various functions is presented. The software platform and the architecture of the invention described below allow third-party and third-party developers to easily and seamlessly integrate into the platform without (or without) knowledge of hosting services. Can develop platform extensions. A third-party developer is a developer who develops an extension of the platform. The fourth-party developer can be a developer who develops an extension to a third-party developer's extension. Therefore, embedding third-party and fourth-party extensions is essentially a transparent process as far as developers are concerned. [0010] For example, consider FIG. 1 showing the user's computer 100 and sources 102, 104, and 106 of a plurality of so-called extensions. The extension source can include any entity that is the source of the software extension over the network. In the embodiment, the Internet can be used as the network, but other networks (for example, LAN and WAN) can certainly be used. The source of the extension can be, but is not limited to, a business entity such as a retail store that can maintain a network site. In one embodiment, the user can run the software on a computer that provides an application program or software platform. As used herein, the terms "application program" and "software platform" are used as equivalent terms. Each of the different extension sources 102-106 can provide software extensions that can be plugged into the software platform running on the user's machine. These extensions can be distributed over networks such as the Internet, which makes it easier to provide applications that can run on the user's machine. In the above embodiment, these extensions are logically described in XML in the light of emerging industry standards. In addition, XML makes it easier to discover extensions in the future by promoting XML DOM properties to the Internet. However, it will also be appreciated that any suitable form for writing an extension can be used, for example a binary description. [0011] Extensions can be distributed from various extension sources, and there can be any number of those sources. The methods and systems of the present invention provide a streamlined and organized way to handle the extensions provided. XML is advantageous because it allows you to efficiently process extensions from different sources of extensions without overburdening software components that utilize specific parts of the extension. .. [0012] In one specific embodiment, the software platform on the user's machine provides a variety of different integrated features that allow the user to perform different document-centric tasks. An example system is described in a US patent application entitled "Single Window Navigation Methods and Systems" incorporated by reference above. [0013] Computer environment example The embodiments described below can be used in connection with various computer systems. For the purposes of this document, a computer system can be thought of as a type of processor, a microprocessor, and any computing device, including some type of operating system. Therefore, a computer system can be interpreted as including, but not limited to, a conventional desktop computer and various portable devices such as a high-performance server, a mobile phone, and a pocket computer device. [0014] FIG. 2 merely shows an example of a computer system that can be used to implement the embodiments described herein. Computer 130 includes a bus 136 that connects various system components such as one or more processors or processors 132, system memory 134, and system memory 134 to processor 132. Bus 136 represents any one or more of several bus structures, including memory buses or memory controllers, peripheral buses, graphics-only highway buses, and processors or local buses that use different bus architectures. .. System memory 134 includes read-only memory (ROM) 138 and random access memory (RAM) 140. The basic input / output system (BIOS) 142, which contains basic routines that help transfer information between elements in computer 130, such as at boot time, is stored in ROM 138. [0015] Computer 130 also removes hard disk drives 144 to read and write to hard disks (not shown), magnetic disk drives 146 to read and write to removable magnetic disks 148, and CD ROMs and other optical media. Includes an optical disk drive 150 that reads and writes to the possible optical disk 152. Hard disk drive 144, magnetic disk drive 146, and optical disk drive 150 are connected to bus 136 by SCSI interface 154 or some other suitable interface. The drive and associated computer-readable media include non-volatile storage for storing computer-readable instructions, data structures, program modules, and other data for the computer 130. The environment examples described herein employ a hard disk, a removable magnetic disk 148, and a removable optical disk 152, but those skilled in the art can use magnetic cassettes, flash memory cards, digital video disks, and random access. You will find that other types of computer-readable media that can store computer-accessible data, such as memory (RAM) and read-only memory (ROM), can also be used in the illustrated operating environment. [0016] Hard disk 144, magnetic disk 148, optical disk 152, ROM 138, or RAM 140 contains several program modules such as operating system 158, one or more application programs 160, other program modules 162, and program data 164. Can be stored. The user can enter commands and information into the computer 130 via an input device such as a keyboard 166 or a pointing device 168. Other input devices (not shown) include microphones, joysticks, gamepads, satellite dishes, scanners, and more. These input devices and other input devices are connected to the processing device 132 through the interface 170 connected to the bus 136. Monitor 172 and other types of display devices are also connected to bus 136 via an interface such as video adapter 174. In addition to monitors, personal computers typically include other peripheral output devices (not shown) such as speakers and printers. [0017] Computer 130 generally operates in a network environment using a logical connection to one or more remote computers, such as remote computer 176. The remote computer 176 may be another personal computer, server, router, network PC, peer device or other common network node, usually including many or all of the above-mentioned elements associated with the computer 130, but a memory storage device. Only 178 is shown in Figure 2. The logical connections shown in Figure 2 include a local area network (LAN) 180 and a wide area network (WAN) 182. Such networking environments are common in offices, enterprise-scale computer networks, intranets, and the Internet. [0018] When used in a LAN networking environment, the computer 130 is connected to the local network 180 via a network interface or adapter 184. When used in a WAN networking environment, the computer 130 typically includes other means for establishing communication over a wide area network 182, such as a modem 186 or the Internet. Modem 186, which may be internal or external, is connected to bus 136 via the serial port interface 156. In a network environment, the program modules mentioned for the personal computer 130 or a part thereof can be stored in a remote memory storage device. It will be appreciated that the network connection shown in the figure is an example and other means can be used to establish a communication link between computers. [0019] In general, the computer 130's data processor is programmed with instructions stored at different times on various computer-readable storage media of the computer. Programs and operating systems are typically distributed, for example, on floppy (registered trademark) disks or CD-ROMs. Installed or loaded from those media into the computer's auxiliary storage. At least part of these programs are loaded into the computer's main memory at run time. The inventions described herein include these types and various other types of computer-readable storage media, which work in conjunction with a microprocessor or other data processor to perform the steps described below. The instruction or program to be processed is stored. The present invention further includes the computer itself when programmed by the methods and techniques described below. [0020] For illustration purposes, other executable program components such as programs and operating systems are shown here in separate blocks, but such programs and components are placed in different storage components of the computer at different times. It will be understood that it is performed by the computer's data processor. [0021] [0021] Extensions As used herein, "extensions" are deemed to include, but are not limited to, software features and content that can be added to application programs or software platforms. These additions usually give some functionality that was not in the application program before the extension was incorporated, or change the behavior of at least one existing feature. When an extension is incorporated into or directly integrated into an application program, the behavior or behavior of the application program changes to some extent. Extensions provide dynamically added content, such as applications (such as email applications), plugins for extending existing applications (such as fax plugins to email applications), or just the Web. A page can be provided. [0022] In the above embodiment, the extension is described using XML, which is an industry standard text-based markup language. Using XML greatly enhances the extensibility of software content. In particular, a third party authors various extensions and writes them in XML, so that the extensions can be easily integrated into the application program. However, it will be understood that XML describes only one method example that describes an extension and uses it. Of course, other methods can be used. [0023] Extension organization example In the above embodiment, the extension has three separate but related parts, an extension definition file (EDF), a package manifest (PKG), and the code, components, or "bits" that make up or define the extension. It is organized by. The EDF can be a URL (Universal Resource Locator) that allows clients to access the EDF, but it does not have to be associated with the URL. By convention and by choice, the PKG file is placed at the same URL as the EDF. It will be appreciated that the EDF and PKG mentioned above are not required to use the other, respectively. It just so happens that in the example presented in this book, both are used together. For that purpose, each of these features can be used separately and independently. [0024] EDF describes a logical attachment to an application program or software platform, while PKG specifies the physical files and resources used by the extension. There can be a one-to-one correspondence between EDF and PKG. [0025] FIG. 3 shows an example of organization 300 including EDF 302 and the corresponding package manifest (PKG) 304. In the illustrated example, EDF 302 uses XML to describe the logical attachments or extensions of the application program. The corresponding PKG 304 specifies the physical files and resources associated with a particular extension. Examples of file types are shown to the right of PKG 304, but this includes, but is not limited to, HTM, GIF, UDO, XML, DLL, and various other file types. [0026] Extension definition file (EDF) In the above example, EDF is an XML file that logically describes the extension. For example, EDF allows you to write HTML that makes up a user interface (UI), objects that contain code that performs various functions, and so on. EDF can also include all or part of the functionality, including extensions. For example, you can import the HTML that describes the toolbar directly into an EDF file so that the Toolbar Attachment Manager reads it from the EDF file instead of from the URL. The information contained in the EDF is processed (along with the information contained in the PKG) and the appropriate files are automatically installed on the user's computer. This is done sparingly without manipulating the persistent settings of the computer, as seen in the user's system registry. [0027] EDF is implemented in XML and contains various tags associated with various extensions. Various tags can correspond to: -User interface element · Behaviors / Components / Objects Store element -User-defined object Alternatively, something else that represents an extensible point within the application or platform [0028] EDF has the advantage of having an "open schema", which means that third-party developers can extend the extension mechanism to include their own extensions by creating their own tags. In addition, extensions can themselves be extended by other developers. EDF can also include one or more predefined tags. Examples of predefined XML tags for user interface elements can include tags for feature types such as toolbars, accelerators, menu items, and themes. These feature types are captured in the reference above and used in a single navigable window application defined in the table immediately below. [0029] [table 1]<img file="JP4936629B2_D0001.tif" />[0030] Examples of behavior / component / object predefined XML tags include service tags. These feature types are captured in the reference above and used in a single navigable window application defined in the table immediately below. [0031] [Table 2]<img file="JP4936629B2_D0002.tif" />[0032] Examples of predefined XML tags for store elements include tags for content classes and offline data sources. These feature types are captured in the reference above and used in a single navigable window application defined in the table immediately below. [0033] [Table 3]<img file="JP4936629B2_D0003.tif" />[0034] EDF schema In the above embodiment, EDF has a specific XML schema to be utilized. This schema provides a collection of XML tags arranged hierarchically so that information can be easily distributed to software components that require some kind of extension. In the above embodiment, the outside (enclosing tag) of EDF is an "extended function" tag. [0035] Figure 4 shows an example of an extension tag. The "extension" tag can contain one or more of the following attributes: All attributes are optional. [0036] [Table 4]<img file="JP4936629B2_D0004.tif" />[0037] Within an "extension" external tag, one or more child tags are also called "top-level tags". Each top-level tag is associated with a feature type that can be added by a particular extension. Examples of feature types are described in Table 1-3 above. Below each top-level tag is one or more child tags, which are individually associated with a particular feature of the feature type added by a particular extension. [0038] FIG. 5 shows an example of XML schema organization according to this embodiment. For each top-level tag in the EDF, there is a related attachment manager, a software component that receives data associated with the tag and can use that data to incorporate extensions into the platform or application program. Different top-level tags can contain different types of data with different structures because different attachment managers can interpret the data received from the tags in different ways to provide different types of extensibility. This will become clearer in the "Architecture" section below. "Edf : Note that the XML namespace modifier can support open schemas where extensions can provide their own tags and corresponding attachment managers. Tags in the edf namespace are used in the application or software platform's built-in attachment manager. Tags in other namespaces are used by third parties to provide additional extension points. [0039] Package manifest (PKG file) The Package Manifest (PKG) supports the work of organizing and downloading software in the form of multiple files via a network such as the Internet. In the examples presented in this book, PKG is advantageous to use with EDF. However, as pointed out above, the techniques described in relation to PKG are deployed in any suitable scenario where it is desirable to distribute the software independently of EDF and over networks such as the Internet. be able to. Although EDF describes how to logically add extensions to an application program or platform, the role of the package manifest is associated with various extensions that can be organized, validated, and / or provided. It is to assist in updating files. [0040] It is important to consider a few things when designing the distribution mechanism for web-assisted distribution of software content or files. [0041] As much as possible, it is desirable to reduce the size of downloads required during the update and installation process. To address this consideration, split the software content into multiple packages. Each package contains a group of one or more files that perform common or well-defined functions. By splitting the content into separate packages, you can minimize the size of downloads required during installation and updates. Each package is described by a package manifest (PKG), which contains file information such as file storage locations and hash values that can be used for validation or security and versioning. [0042] In addition, it is desirable that the end user can perform the same operation as the operation on the Web. To do this, users can load extensions as if they were loading a web page, rather than waiting for the entire package to finish loading and then interacting with the traditional software package. In the above embodiment, the user interacts with the application program much faster than if the user had to download the extension file to the client by streaming and wait for the entire software application program to finish loading. Since it can be started, it can be operated in the same way as the operation on the Web. For example, when downloading a user interface (UI) image file by streaming, the user can consider the user interface as a stream-in of the file. For example, consider a single application program with multiple different functions as described in the patent application incorporated by the reference above. The user can search the e-mail function and download the files required to interact with the e-mail function. Files associated with other different features will be downloaded after the files associated with the email feature. In this way, the user can initiate an operation within a particular feature without having to wait for all files associated with all other features. [0043] Another consideration of interest concerns the efficiency of distributing extension files or "bits" to clients. To address this consideration, the above embodiments utilize two different download methods: throttle download and background download. In throttle download, the download operation is performed while considering the effective bandwidth used for file transfer and the type of medium. Any suitable throttle download process can be adopted, but those skilled in the art will understand this. The background download is performed while the user is operating the application program and is performed by allocating a background thread so that the user can continue the work. One of the optimization techniques used is to prioritize and distribute packages according to the user's work. [0044] Another consideration concerns optimizing computer operations by users. Here, the operation by the user is optimized by preparing the most common scenario for the user. It is effectively aimed at providing users with the functionality they need first, and then in the background download process, providing code that implements the functionality that they expect to use in the future. There is. To determine the first feature the user thinks they need, provide an automated scenario-based packaging process that runs against the file usage log of the scripted scenario. [0045] The following sections detail these considerations and the solutions of the invention for which it is intended to address those considerations. [0046] Package manifest definition In the above embodiment, the package manifest (PKG file) comprises a list of files used within the package. It is advantageous to compress this list slightly and include a digital signature. Each package manifest contains a list of one or more files, and each file can contain associated hashes and download directives that control the caching of the files. Once the extension is authored, software tools can be used to generate the package manifest. [0047] In addition, the package manifest allows you to specify multiple other pieces of information. [0048] -File group All files in the extension can be labeled according to some predefined file groups. The file group of a particular file determines when to download a particular file, where it is stored on the client, and how it is packaged. In the above embodiment, four types of defined file groups are prepared, which are listed in the table below. [0049] [Table 5]<img file="JP4936629B2_D0005.tif" />[0050] -File download priority The files in each group are arranged in the order of download. This download order is implicitly set in the order of the files in the package manifest, as shown in Figure 6. [0051] · Security / versioning hash value You can assign associated hash values to individual files in the package manifest. Each hash value is generated by processing the file with an encryption algorithm. Microsoft's CryptoAPI is an example of an encryption algorithm. In the illustrated example, each file is based You can list it with a 64-encoded hash value to validate the file when the content arrives at the client. In particular, the package manifest is securely sent to the client (that is, it is digitally signed). The package manifest contains hash values for individual files. When the client receives the individual files, they can process each file with the same CryptoAPI used to set the hash value in the package manifest. If the hash values of a particular file are not inferior, then the file has not been modified and is safe. [0052] When updating a file, the hash value can be used for the useful purpose of identifying files that have not changed between different versions of the extension. For example, consider Figure 7. So, in the previous directory 700 in the client package cache, Package A, which contains two files, file 1 with hash = x and file 2 with hash = y, is placed. This package is assumed to be associated with an older version of the extension. When you generate an updated version, the package manifest is distributed to clients. The updated extension version is represented in the code or in the source directory of web server 704. The package manifest contains hash values for all files in the new extension version. The new client destination directory 702 is defined for all files in the new extension. If all the hash values for the files in the new extension are the same as the hash values for the files in the old directory 700, you can copy those files directly from the old directory 700 to the new destination directory 702. In this example, the hash value for file 1 is the same as the hash value for file 1 in source directory 704 and can be copied to the new destination directory 702. However, the hash value of file 2 is different from the hash value of 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 added and will be downloaded from the code server. Therefore, in this example, the result of the new version of the extension is less downloads than all the files in the extended version. This is because the hash value for each file in the old extended version could be compared to the hash value in the file for the new extended version. Hash values that are the same value have changed between versions [0053] The method of using hash values for versioning has two major advantages over traditional versioning methods. One is that the update process is automated. This means that an explicit version number can cause you to forget to update the version number when a new release of a file is shipped. You can work around this problem by using a hash value. Second, versioning is file type independent. In particular, the traditional versioning method generally embeds version information in a file, but does not support version information in which all files (for example, GIF files) are embedded. In this example, the method of using hash values for versioning does not depend on whether a particular file type supports embedded version information. Further, the version information can be stored separately from the file itself. Therefore, you don't have to access the actual file to see if it's up to date. [0054] Total storage size of the package Use the total storage size of the package when downloading and make sure that the user has enough disk space. [0055] -DLL ClassID A listing of the ClassID of each DLL is required to allow scripters to create classes against OM. In addition, this allows you to find out which package contains the code for a particular class. [0056] -DLL load dependency The dependency section is there so that you can use legacy code that depends on being loaded because it is in the search path of other dlls. In this case, you need to make sure that the dependent dll is in the package cache directory before loading the dependent dll. Figure 6 shows an example package manifest 600 defined in a hierarchical tag-based language. It is advantageous for tag-based languages to adopt XML, which is desirable in terms of extensibility and flexibility. In this example, some tags are prepared in a hierarchical array. The "package" tag contains information about the size of the package. The "files" tag is a child of the "package" tag and stores information about the filegroups contained in a particular package. The "file" tag is a child of the "group" tag and contains information about a particular file with extensions, namely the filename and hash value. The "dependency" tag is provided as a child of the "file" tag and lists the dependencies as described above. The "COMClass" tag is also provided as a child of the "file" tag and contains the ID as described above. The file group order of this method implicitly defines the file download order. [0057] Package distribution Use two different distribution methods for optimal package distribution. One is to use the throttle download method using the known throttle download method. Here are some considerations such as effective bandwidth and media to use when providing extensions. [0058] [0058] The second is to use the background download method. Background downloads allow users to continue working within the application program while downloading content. Foreground downloads are for downloads of files that are not locally available, for example, when the user clicks the extension link to explicitly request a file / extension, or, for example, clicks the "Compose" email button. Used when requesting the required action. [0059] Along with background download, you can also get a queue management function. In particular, when an extension needs to be installed or updated, it provides the following information to the package manager, which is essentially the software component that manages the package: -URL of package manifest information about code server · URN of the package destination directory in the client's package cache · (Optional) URN in the old package directory (if it exists) in the package cache [0060] From this information, the package manager creates a package object and adds it to the download queue. The download queue is designed to facilitate reordering the package download order. For example, consider Figure 8, which shows a portion of the download queue 800 that contains two package objects, Package Object 802 (corresponding to Package A) and Package Object 804 (corresponding to Package B). The package object holds a list of files for the corresponding package that has been downloaded or installed. In this example, files 1 and 2 of package A are installed but file 3 is not installed, and files 1, 2, and 3 of package B are not installed. Download queues can be rearranged based on what the user does. In other words, you can change the priority of downloaded files based on the actions taken by the user. In this example, the package manager is designed to handle the first uninstall file in the package at the top of the download queue. However, if the user starts using a file with an extension that is different from the extension at the top of the download queue, the corresponding package of the file that the user started using can be moved to the top of the download queue. The file's package is specified by its URN, so the file's package can be quickly identified and found in the download queue. For example, considering Figure 8, if one of the files in package B is requested before the package manager starts installing the third file in package A, package B will be moved to the top of the download queue. [0061] FIG. 9 is a flow chart illustrating a plurality of steps of the download queue management method according to the embodiment. This method can be performed with any suitable hardware, software, firmware, or a combination thereof. In this example, this method is implemented by software. [0062] In step 900, you receive one or more requests for the extension. The request can be generated in any suitable way. In step 902, create a package object for each extension package you download. In step 904, arrange the package objects in the download queue. Then, in step 906, the file corresponding to the package object in the download queue is downloaded. This step can be performed, for example, by starting at the beginning of the download queue, downloading the files until all the files in the package object have been downloaded, and then moving to the next package object. At step 908, check if the user action requires a file that is not described in the current package object. If the user's action does not require a file not described by the current package object, this method branches back to step 906 and continues downloading files associated with the current package object. On the other hand, if the user's action requires a file that is not described in the current package object, step 910 moves the package object associated with the required file to the top of the download queue and relocates this newly. Start downloading files associated with the package object. This step can be performed by checking which package object is associated with the required file by checking the file and associated URN. This URN allows you to specify a package for a file to quickly find a package object and move it to the top of the download queue. [0063] Package creation One of the innovative features of the above embodiment is extensibility. That is, it provides the software platform in the form of application programs that can be extended by various third-party user-defined extensions. These extensions will be distributed on the Web and integrated directly into the software platform. To provide a well-organized distribution process, create packages in a unified way, process them in a predictable way, and integrate them into your software platform. [0064] According to the above embodiment, each package needs to correspond to the end user function. For example, the patent application incorporated by the reference above provides separate packages for email, contacts, document authoring, and planner features. If packages that do not depend on each other share a dependency, this shared dependency must be a dedicated package. For example, there is no reason why email and document authoring capabilities need to depend on each other, but both do need the ability to publish content. By separating the publishing functions into a dedicated package, some flexibility in the download order is ensured. Depending on what the user starts working on, the file corresponding to the email function or document authoring can be downloaded first. [0065] FIG. 10 is a flow chart illustrating a plurality of steps of the package creation method according to the above embodiment. This method can be performed with any suitable hardware, software, firmware, or a combination thereof. However, each part of this method can be performed manually. [0066] In step 1000, identify the end-user functionality that you want to provide as an extension. In step 1002, identify the shared dependencies between end-user features. In step 1004, create a separate package of end-user features. In step 1006, create a separate package for the shared dependencies between end-user features. [0067] Automation package manifest creation tool One embodiment provides an automated package manifest tool, which is advantageous because it accepts various input parameters and automatically creates a package manifest. This tool can be used to assist third parties in creating package manifests. [0068] FIG. 11 shows an example package manifest creation tool 1100, preferably implemented in software. In this particular example, the tool can accept the following input parameters (some are optional): · Extension directory · Filegroup information and DLL load dependencies (optional) -File usage statistics of scenario execution results (optional) [0069] The extension directory input parameter specifies the directory that contains all the files described by the package manifest. If this is the only parameter, Tool 1100 will generate a manifest where the EDFs and DLLs in the directory are listed in the "Required" set and all other content is "Offline". [0070] File group information and load dependency parameters are optional. If the extension author knows the category in which their files should be placed, that category must be specified here. For example, the creator of the template manifest shown below knows that he wants to include his error-handling GIF in the package requirement set. The choices here are always respected in the final manifest. In addition, if the extension author knows about DLL load dependencies, they also need to be specified here. [0071]<img file="JP4936629B2_D0006.tif" />[0072] The file usage statistic parameter from the scenario execution result is an optional parameter. With this parameter, the priority of file download can be determined based on the scenario execution result. A scenario is a script of tasks that the average user typically follows when using a product during a particular part of the period of use of the product. For example, there are scenarios related to tasks related to sending email messages (that is, clicking the New Mail button, filling in the To field, filling in the Subject field, and so on). In the above embodiment, file usage statistics from scenario execution results are collected by taking IIS logs for various scenarios. In different scenarios, some probabilistic support tends to ensure that the file download order somehow reflects the file that the user is likely to use first. [0073] It will be appreciated that file usage statistics can be dynamically provided by building a knowledge base that describes the actual work that a user normally performs. The information held in the knowledge base can then be used to generate and adapt download scenarios that actually fit the patterns established on the user base. [0074] If an extension author attempts to pass this information to the Package Manifest Creation Tool 1100, it must specify the start and end dates of the sections of the log that the tool analyzes, along with the log directory. For third parties, the download priority order within the group will be the order requested in the log of the group's files across all scenarios. [0075] In one embodiment, this method is somewhat advanced. Additional information (in addition to script steps) is stored in the IIS log, including scenario priorities and checkpoints. The scenario priority is the priority assigned to each scenario. So, for example, if one scenario is 10 times more important than the other, this information can be retained. The priority (for example, rating from 1 to 100, with 100 being the highest priority) is equal to the best guess as a percentage when the user runs the scenario step by step, assuming that they will use the extension anyway. There must be. Checkpoints are a means of distinguishing one scenario from the other. For example, checkpoints designated as "Offline" and "Shutdown" can be automatically added to the beginning and end of a scenario, respectively, to distinguish between scenario execution results in the log. In addition, script authors can optionally use checkpoint intermediate scenarios to indicate group priority changes, for example, "On" in some scenario scripts. You can also label it as a "demand" feature and label the rest as "Offline". [0076] FIG. 12 is a flow chart illustrating a plurality of steps of the package manifest creation method according to the above embodiment. This method can be performed with any suitable hardware, software, firmware, or a combination thereof. In the above example, various steps of this method were performed with a manifest creation tool implemented in software. [0077] At step 1200, provide a package manifest creation tool. This tool may be a software tool located on the extension creator's machine. In step 1202, receive the information related to the extension directory as the first input parameter. The step determines if there is any filegroup or load dependency information provided by the extension author. If so, in step 1206, receive the information as an input parameter. At step 1208, determine if there is file usage statistics information. In one embodiment, such information can be obtained using the scenario execution results as described above. Once such information is obtained, the information is received as an input parameter in step 1210. In step 1212, all the information obtained is used as an input parameter to automatically generate a manifest. [0078] Example of file ordering discovery method based on file usage statistics FIG. 13 is a flow chart illustrating only one file ordering or rearranging discovery method according to the embodiment. It should be understood that this particular example is only a means of ordering the files to be downloaded. Therefore, other discovery methods can be used without departing from the spirit and scope of the claimed subject matter. [0079] In step 1300, sort the files by file group. In the example shown above, the files are grouped by Required, Offline, On Demand, and Online. Can be in one of four groups of Only. The group of files is first determined by the manifest, and if no group information is provided, it is determined by the highest priority group used, depending on the checkpoint information in the log. Files in the "Required" set do not need to be considered as their order is already known. If no group information about the file is included, assume that the EDF and DLL are "Required" files and all other files in the directory are "Offline". [0080] [0080] For example, consider the following initial file usage information for three different scenarios. Scenario 1 File usage: 1) FileA.gif, 2) FileB.xml, 3) FileE.dll Scenario 2 File Usage: 1) FileC.xml, 2) FileA.gif Scenario 3 File usage: 1) FileD.js, 2) FileA.gif Scenario 1 = Priority 80 Scenario 2 = Priority 80 Scenario 3 = Priority 40 [0081] In this example, there are three scenarios with related files. Each scenario is assigned a related priority. The files are first sorted by group (step 1300). Note that in this ordering discovery technique, DLLs are considered "Required" and all other files are considered "Offline". This will give you the following sorted files: Required file FileE Offline file FileA, FileB, FileC, FileD [0082] In step 1302, sort the files (highest to lowest) based on scenario priority. High priority files are ordered to be downloaded first. This step gives you the following sorted files: Required file FileE Offline file Priority 80 Group: Files used in Scenarios 1 &amp; 2 = FileA, FileB, and FileC Priority 40 Group: File used in Scenario 3 (not already listed) = FileD [0083] Next, in step 1304, the files are sorted according to the file usage order in the scenario execution result. For each priority grouping that uses multiple files, the files are sorted based on the average order downloaded within the labeled priority scenario. Scenarios with a small average usage order are downloaded first. Ties are discarded based on the order in which the scenarios appear in the input file. For example, consider the following. FileA: Average order = (Scenario 1 order + Scenario 2 order) / 2 = (1 + 2) / 2 = 1.5 FileB: Average order = (Scenario 1 order) / 1 = (2) / 1 = 2 FileC: Average order = (Scenario 2 order) / 1 = (1) / 1 = 1 [0084] Here, file A is used first by scenario 1 and second by scenario 2, averaging 1.5 and so on. File C has the lowest sequence number of the Offline files, so it is sent first. The last file order is shown below. Required file FileE Offline file FileC, FileA, FileB, File D [0085] Code, components, and "bits" The following files and resources can be attached to the extension, but they are not required. This list is not exclusive and of course other resources can be incorporated into the extension. · Customized UI and keyboard shortcuts · Components / behaviors · XML browse and edit components (including XSL and business logic objects) · Static pages or other resources Third-party defined custom content [0086] The user navigates to the network site in search of the extension and installs the extension. In the Internet embodiment, the user navigates to the appropriate URL to look for the extension. The hosting administrator can also "push" the extension so that the user automatically receives it by adding an entry to the appropriate user's "Preferences" settings. [0087] Platform setup and extension installation FIG. 14 is a flow chart illustrating a plurality of step examples of the setup and extension installation process according to the embodiment. This example describes an internet-based example. In the illustrated example, there are various extensions that are held and accessible through various Internet sites. These extensions can be distributed to clients via the Internet. It will be understood that the computer divisions shown in the figure are not always real. For example, all the functionality provided by a computer can be resident on one machine, extensions can be located locally, or platforms and extensions can be located on the same machine. [0088] In this example, a flow diagram is shown for three separate "zones", one representing the client, the other representing the "platform" internet server, and the last one representing the third party internet server. Represent. The actions described for different zones are performed by the entities assigned to the zones in this example. In some configurations, one or more of these zones may overlap. For example, a platform server may have extensions on the same device as the server. [0089] At step 1400, the user navigates to a specific Internet site associated with the software platform used as the basis for the extension installation described below. At step 1402, the user clicks the Install button and sends a message to the software platform server indicating that the user wants to install the software platform. This step can be an optional step. In steps 1404 and 1405, download the software platform and associated software to the client. In the illustrated example, step 1404 downloads the package file for a single navigable window application, and step 1405 downloads other components and files to the user's computer based on the contents of the file. At step 1406, you can install the software code on the client machine and create a local directory for the application cache, local store, and preferences. However, it will be understood that a local directory or preference is not always necessary. At step 1408, the software platform is launched. [0090] The steps described above are the steps associated with the initial setup for distributing and installing the software code for a single navigable window application on client machines. The steps described below relate to extension installation. [0091] At step 1410, access the extension using the link associated with the extension. This step allows the user to navigate to a particular Internet site in a browser and access one or more extensions. Separately, the reference to the link can be placed within the user's preference or the preference of the compute group with which the user is associated (for example, the system administrator places the reference within the group's preference). be able to). It is advantageous to associate this link with a third party internet server or internet site. In step 1412, download the extension file according to the PKG associated with EDF. The file is distributed to the client and in step 1414 the extension file is stored in the local store specified by the PKG specification. At this point, the extension is installed and the user can take advantage of the functionality provided by this extension. At step 1416, determine if an extension update is available. This is done by periodically polling the extension catalog (discussed in the "extension catalog" section below) to see if there are any updates for various extensions. Alternatively, you can automatically notify the client of updates, or use other methods to determine if updates are available. If the update is available, step 1418 branches to step 1412, downloads the extension files associated with the update, and installs them on the client. [0092] Extension development The task of developing extensions for a particular software platform is a relatively straightforward process. Developers use tools such as Notepad and other tools such as Visual Studio to develop extension content. Then write the extension in EDF and PKG, digitally sign the PKG, and optionally compress it. The extension can then be hosted on a particular network server. [0093] FIG. 15 is a flow chart illustrating a plurality of steps of the extended function development method according to the embodiment. A software developer or organization that creates a particular extension can perform one or more of these steps. Some of the steps are performed in software. At step 1500, develop the extension. You can use any suitable tool to develop the extension. In step 1502, create an extension definition file (EDF) for that extension. In this example, EDF is defined using XML as described above. Of course, other formats can be used to describe EDF. In step 1504, create a package manifest (PKG) for your extension. In this example, the PKG is defined using XML as described above. In step 1506, host the EDF and PKG on a network server such as an internet server. In addition, the associated extension files described in the PKG can also be hosted on a network or internet server (step 1508). The user who has done the above then navigates directly to the EDF (for example, using the relevant URL or some other network address), caches the required files locally, and makes a reference to the extension for the user. Install the extension by putting it in your preferences. [0094] In particular, step 1510 distributes the EDF and PKG files to the clients. This step allows the user to navigate to a specific internet site where the appropriate file is hosted and download the file. At step 1512, the extension files associated with the EDF and PKG files can be distributed to the client and then installed and used. [0095] Extension Catalog An example of an optimization briefly described with respect to Figure 14 is to add an extension or the level of induction found in EDF in the EDF catalog. The EDF Catalog allows organizations to group extensions and provide a single place to determine when extensions change. The desired extension can be automatically selected from the catalog by the software platform based on the user's settings. You can query the catalog to determine which extension is best for you. [0096] In the above embodiment, the catalog is an XML file that contains a mapping of extensions from URNs to URNs of one or more packages based on language, version, or other attributes. However, the catalog can be defined using any suitable format. The catalog can have the following functions. · Hosting organizations can update version information about one or more hosted extensions in a single location. -You can use the optional automatic direction to the correct version based on the user's settings. For example, you can list multiple versions of extensions for different languages in the catalog. The catalog file can be processed to search for changes to the version of the extension that match the user's language settings. · You can optionally automatically upgrade to a new version of an extension when it becomes available. [0097] Like EDF, catalogs can be compressed and digitally signed to prevent tampering. The number of server pings (or notifications) required by the client to discover extension updates by subscribing to the catalog and detecting changes to one or more hosted extensions. Can be reduced. [0098] Figure 16 shows an example of an XML catalog structure. The structure of the entries in the catalog is as follows: [0099] [Table 6]<img file="JP4936629B2_D0007.tif" />[0100] In this particular example: -The default language of netdocs-planner is the English version. -The default English version is 1.1. The default French version is 1.0. If there is no version available for the user's specified language on the platform, get English version 1.1 by default. -The English version of netdocs-planner has been upgraded from V1 to Vl.1. There is also a French version. The URN of the extension is the same as the English version. There is no 1.1 release for the French version, 1.0 is the latest version for French users. · When querying the catalog, only rows whose language matches the user's language preferences are returned. It also returns all lines where the language is the user's language or default = yes', and duplicates with the same name are discarded. [0101] architecture In the above embodiment, one aspect of providing the desired utility is the extensibility of the software platform. That is, third-party and fourth-party developers are free to develop their own extensions that can be used within the framework of the software platform. Extensions are integrated directly into the software, and platform feature changes are made by the extensions. Note that to have an extension, the developer simply authors the extension, writes the extension in EDF and PKG, and hosts the EDF, PKG, and related files on the network server. I want to. [0102] EDF can be defined in an XML Schema that contains a root node (that is, an "extension" tag) and one or more child nodes, as pointed out above. In this particular example, the child nodes generally correspond to the functional type of the individual extension that is desired to be incorporated into the software platform. Note, for example, Table 1-3 above provides examples of different predefined feature types that extensions can add using a predefined XML schema. [0103] So the developer wants to add two menus and one toolbar to the software platform. Menus and toolbars can be associated with retailers that maintain websites for their customers. A retail store may want to show a customer who visits a website a unique UI to the retail store, and provides a service that has been specially tailored to the store. To that end, developers have developed two different menus, one associated with displaying the most recent featured products, and the other a search mechanism for users to search for a particular product. Can be associated with providing. The toolbar can have its own unique buttons for the retail store. A simple EDF named "retail. Edf" for retail store extensions is shown just below. [0104]<img file="JP4936629B2_D0008.tif" />[0105] Here, the outer "extension" tag specifies this XML file as an extension. The inner "menus" and "toolbars" tags are top-level tags, indicating that the information between these tags pertains to the menus and toolbars that correspond to the extensions added by the developer, respectively. The bold "menu" and "toolbar" tags describe data about the actual extension and include URLs associated with each of the above extensions. The EDF above logically describes an extension that is prepared to include two menus and one toolbar. [0106] Also note that the EDF above is only one of many EDFs loaded into the system. Each EDF can contain one or more top-level tags, each associated with one or more specific extensions added to the software platform. [0107] Figure 17 is a block diagram of an example software architecture that is configured to handle multiple different EDFs, with software components responsible for incorporating each particular extension into the software platform as appropriate for that extension. Receive information. This example is specific to the XML embodiments described throughout this document. It should be understood that other architectures that are functionally similar to those described below can be used in other embodiments without departing from the spirit and scope of the subject matter of the claims. [0108] A utility object, called an attachment point, is used to process information from multiple EDFs. An attachment point is just a collection of objects that fires an event to a registered listener, and the fire of an event occurs when an object is added to or removed from the collection. You can create many types of attachment points, but all retrieve data from the source (often other attachment points), process it (dynamically or statically), and publish the results. The simplest attachment points are: An XML attachment point that loads an XML file and exposes the top-level node of the XML as an object in its collection. -A filter attachment point that connects to another attachment point and exposes only objects that meet some criteria from it. A merge attachment point that connects to one or more other attachment points and exposes all of its objects as one merged collection of objects. [0109] In the illustrated example, the architecture includes a collection of one or more attachment points, including a funnel structure called EDFHub 1700, an attachment point manager 1702, and multiple attachment managers 1704. EDFHub 1700 takes all of EDF, merges it together, and publishes it as a single list. Other individual attachment points are EDF Hub It has a mechanism for manipulating a single list exposed by the 1700 (including filtering, merging, and expanding). Arrange for various attachment points to notify the appropriate attachment manager when new extensions or EDFs are added or removed from the EDF Hub. This is done by invoking an event to the appropriate attachment manager. Attachment Point Manager 1702 creates, destroys, and manages various attachment points in the system, making it easy to reuse the same attachment points. [0110] For each top-level tag (that is, the "menus" and "toolbars" tags), there is a corresponding Attachment Manager 1704 that incorporates a particular feature type within the software platform using the data provided by the attachment points. Each attachment manager requests a set of attachment points from the attachment point manager 1702. These are EDF Hub Manipulate the data published by the 1700. In the illustrated example, attachment points can be requested as a predicate chain that the attachment point manager uses to create and build a set of attachment points that act on the data exposed by EDFHub 1700. [0111] FIG. 18 is a flow chart illustrating a plurality of steps of the method according to the embodiment. This method is performed by software, and in this example the software component of FIG. [0112] Step 1800 receives multiple EDFs. Those files can be received in any suitable way. For example, users can specify in their preferences the specific extensions they want to load when they come online. Separately, the user may navigate using a link to a specific internet site that recognizes that the user is running a software platform that is configured to dynamically add extensions. it can. In this example, EDF combines EDFs using attachment points (step 1802) EDFHub Pour into 1700. In this example, EDF is defined as an XML file and the nodes are combined into a single XML list. Step 1804 publishes the combined EDF. In this particular example, the EDF is combined with a single XML list exposed to various other attachment points that further manipulate the data (step 1806). One goal of the attachment point is to prevent the attachment manager 1704 from repeatedly querying the entire system each time an extension is added to or removed from the system. Therefore, when adding or removing an extension, the attachment point ensures that the particular addition or removal of the extension is notified only to the applicable Attachment Manager 1704. For example, if EDF tells you to add a menu, only the attachment manager associated with the menu will be notified. Therefore, in step 1808, the appropriate attachment manager is notified of new data that meets the attachment manager's requirements. [0113] Attachment Points and Attachment Point Manager An attachment point is an object that exposes a collection of ordered objects and triggers a notification when a new object is inserted or deleted. In the system example, the object is an XML node, but it can be any kind of object. There are many different types of attachment points, but they all follow a similar process: 1) First connect to one or more data sources. These can be files or, in general, other attachment points. 2) Process the data based on some logic. This logic is usually quite simple and may involve operations such as filtering objects based on some criteria. 3) Publish the result of process step 2 in collecting new objects. 4) Fire an event that indicates how the published collection of objects has changed (OnInserted (index, count) or OnRemoved (index, count). Five) Optionally, keep an eye on changes in the data source and repeat steps 2-4 when changes occur. [0114] However, each attachment point is extremely simple, but when processing data from a second attachment point with one attachment point when a "chain" is formed by combining different types of attachment points, this process is performed. Can be extremely powerful. This is correct, especially if the attachment points only process the data that was modified in step 2, as they only do a small amount of simple work at once. The system example shows that this incremental process eliminates the need to query the entire system again when a new extension is installed or an existing extension is removed. In addition, each attachment manager in the example system uses a chain of specific attachment points, so it only notifies changes that affect the extensible area. [0115] The Attachment Point Manager performs two important functions when building a chain of attachment points. One is the ability to describe the chain as a predicate string. The Attachment Point Manager interprets those strings and builds the required chain of attachment points. The other is the ability to reuse the same attachment points, which increases the efficiency of the system. When the Attachment Point Manager creates each chain of attachment points, it keeps track of which predicate string corresponds to which attachment point. Easily reuse an existing attachment point without creating a new one if the predicate string is requested again later. [0116] For example, suppose the attachment manager associated with a menu requests the following predicate chain for attachment points that utilize the retail.edf file above (Note: this example does not assume the existence of EDFHub attachment points): .. [0117] Explode (Filter ("menus", " Explode (URL ("retail.edf")))) [0118] This string represents all the menus in the retail.edf file. The XML file located in retail.edf is loaded by a URL attachment point that exposes the root node of the XML file as the only object in its collection. The inner explode attachment point uses the URL attachment point as its data source and collects the source. and exposes all the children of the object . In this case, the children of the root node are the top-level XML tags "menu" and "toolbars". Filter attachment points use explode attachment points as their data source to filter exposed objects that look only for nodes that are "menus". The outer explode attachment point uses the filter attachment point as its data source, exposes all the children of the filtered menu node, and outputs a list containing the two menus added by the extension. This particular XML file contains the menu identified by the menu attachment manager and the associated attachment point, so the attachment manager is notified that the extension has added two menus. [0119] This process, graphically shown in FIG. 19, shows attachment points 1900, 1902, 1904, and 1906. Each attachment point exposes a list of XML nodes. URL Attachment Point 1900 receives input (URL to an XML file-for example, retail.edf-) and exposes a list of XML nodes. This list contains only the root node "&lt;edf: extension&gt;". Explode attachment point 1902 takes attachment point 1900 as input and exposes a list of XML nodes that are children of the source XML node. In this example, the list of XML nodes exposed by Attachment Point 1902 is the "&lt;menus&gt;" and "&lt;toolbars&gt;" nodes. Filter attachment point 1904 receives attachment point 1902 as input and filters it with "menus". Next, publish an XML list that contains only the "&lt;menus&gt;" node. Explode attachment point 1906 takes attachment point 1904 as input and exposes a list containing the XML nodes contained in the "&lt;menus&gt;" node-here both the "&lt;menu&gt;" nodes. [0120] In addition, consider that the toolbar attachment manager requests a predicate chain for URL attachment points, explode attachment points, and attachment points that also use the filter attachment point 1904 to filter by "toolbars". Therefore, the corresponding explode attachment point 1906 exposes an XML list containing only the "&lt;toolbar&gt;" node. However, the Attachment Point Manager detects the commonality between the URL attachment point and the inner explode attachment point and reuses the same attachment point created for the Menu Attachment Manager. The filter attachment points used by the Toolbar Attachment Manager and Menu Attachment Manager use the same Explode Attachment Points as their data source, but expose different node collections because they were filtered based on different criteria. [0121] Consider Figure 20, which incorporates the EDF Hub Attachment Point 2000. This attachment point takes all of the EDFs and combines them into a single XML list, as described above. EDF Hub then exposes the root nodes of all EDFs. Explode Attachment Point 2002 exposes an XML list containing all of the top-level nodes of all EDFs. For example, there can be multiple EDFs, each containing a top-level menu node, a toolbar node, an accelerator node, and so on. Explode Attachment Point 2002 exposes an XML list containing all of their top-level nodes in all EDFs. Filter Attachment Point 2004 can then filter the XML list exposed by Explode Attachment Point 2002 according to any appropriate parameters (ie, filter by menu node, toolbar node, accelerator node, etc.). The final Explode Attachment Point 2006 exposes a list of individual child nodes in the list exposed by Filter Attachment Point 2004. This list lists all the specific features (of the specific type that have been filtered) added by all EDFs. [0122] The table below lists some different attachment points that are available in the above embodiments, but more can be easily created. [0123] [Table 7]<img file="JP4936629B2_D0009.tif" />[0124] Conclusion The embodiments described above provide a platform solution that enables customization and extensibility through a consistent logical extensibility mechanism and object model that third-party developers can easily understand. Performing Internet-based downloads requires little user intervention and requires no user-permanent configuration manipulation. Extensions can be dynamically added to software platforms or application programs based on the user's computing status. [0125] Although the present invention has been described in a language specific to structural functions and / or methodological steps, it is understood that the invention defined in the accompanying claims is not necessarily limited to the particular function or step described. Will be done. Rather, the particular function and step is disclosed as a preferred embodiment of the claimed invention. [Simple explanation of drawings] FIG. 1 is a high-level diagram of a system available according to one embodiment described. FIG. 2 is a diagram of an example computer system that can be used according to the embodiment. [Fig. 3] It is a figure of the example of EDF and PKG by one embodiment of the description. FIG. 4 is a partial view of EDF according to the embodiment. FIG. 5 is a partial diagram of an EDF schema according to the embodiment. FIG. 6 is a partial view of a PKG according to the above embodiment. FIG. 7 is a block diagram showing a method of using a file hash for versioning according to one embodiment. FIG. 8 is a block diagram showing an example of two package objects according to one embodiment. FIG. 9 is a flow chart illustrating a plurality of steps of the method according to the above-described embodiment. FIG. 10 is a flow chart illustrating a plurality of steps of the method according to the above-described embodiment. FIG. 11 is a block diagram showing an example of a package manifest creation tool according to the above embodiment. FIG. 12 is a flow chart illustrating a plurality of steps of the method according to the above-described embodiment. FIG. 13 is a flow chart illustrating a plurality of steps of the method according to the above-described embodiment. FIG. 14 is a flow chart of a plurality of steps of the method according to the embodiment. FIG. 15 is a flow chart of a plurality of steps of the method according to the embodiment. [Fig. 16] It is a figure of a part of the catalog structure example by the said embodiment. FIG. 17 is a block diagram of a software architecture according to the embodiment. FIG. 18 is a flow chart of a plurality of steps of the method according to the embodiment. FIG. 19 is a diagram showing one aspect of the attachment point architecture according to the embodiment. FIG. 20 is a diagram showing an aspect of the architecture of FIG.