Centralized application package distribution

A package installer identifies a utility tool that is capable of opening a file attempted by a user based on metadata downloaded from a remote server, where the metadata includes information identifying one or more packages available for download from the remote server, including mime types of files that the one or more packages support. A graphical user interface (GUI) is displayed to the user prompting whether the user desires to install the identified utility tool. In response to an input from the user via the GUI, the package installer downloads a package associated with the identified utility tool from the remote server for local installation.

TECHNICAL FIELD

Embodiments of the invention relate generally to the field of software application distribution; and more particularly, to centralized application package distribution.

BACKGROUND

People often send other users documents and images. These files are often of different formats, as a user could send a Microsoft Word file (.doc file) or a GNU image manipulation program (GIMP) image (.xcf) via email, instant messaging or even on physical media.

There is a problem in a desktop such as Linux desktop, where people send files that are not recognized by a remote user. This might happen if a user sent a remote user a “.xcf” formatted image, when GIMP was not installed at the remote user's machine. In this case the remote user would get the “file not recognized” dialog, and would be left to search for a program manually to open this file. This requires for the remote user to know which program to use to open the file.

Conventional methods typically will prompt a user whether the user wants to search, for example, over the Internet, for such a program to open the file. However, the program to open the file may be distributed in multiple sites having multiple versions. The user has to know which version is the most appropriate for opening the file.

DETAILED DESCRIPTION

When a package is built, each application has a desktop file created as a standard part of the build process. According to one embodiment, by parsing a file for mime-type matches, each mime type is added as a virtual provide to the built package. This virtual provide is added to the distribution metadata which allows remote programs to query what package supports a given mime type. In Linux this is done using a WhatProvides( ) method, typically via a package manager such as PackageKit available from Red Hat, Inc. of Raleigh, N.C. An example query would be WhatProvides (“MimeHandler(application/pdf)”) which would return a list of all the not-installed packages that would be able to open this file format. By providing a tool to extract the mime data at package build time, many of virtual provides can be automatically added just by rebuilding all the packages in a repository on a storage device.

A mime type is a computer readable file type. For example, a “.pdf” file is the mime type of portable document format (PDF) files. A mime type can be extracted from a file even if the file extension is incorrect (.doc is mistyped as .dpc for example) and usually a higher level of file system logic is used to do this content sniffing. In the Linux desktop GNU virtual file system (GVFS) provides a mime-type as an attribute on a GFile instance.

A desktop file is a file that is installed on the computer that describes the application (localized name) and also tells the computer what mime-types it supports. A virtual provide is a little piece of data about the package that resides in the distribution metadata, and thus the package does not have to be installed to query this data.

By integrating this functionality into a file handler (in the case of GNOME, nautilus) or as a separate tool accessible to the file handler, when a user downloads a file of unknown format, the file handler tries to open the file and provides a list of applications the user can install which is capable of opening the newly downloaded file. After the packages are installed, the file handler uses the installed application to open the downloaded file. In this way a user can send files to remote users knowing that they will be able to open the contents.

FIG. 1is a block diagram illustrating a network configuration according to one embodiment of the invention. Referring toFIG. 1, network configuration100includes a client101communicatively coupled to a server102over a network. Client101can be any kind of computing devices such as desktop, laptop, personal digital assistant (PDA), or cellular phone, etc. Server102may include one or more computing devices such as a Web server for distributing software packages that can be downloaded by client101over network103. Network103may be local area network (LAN) or a wide area network (WAN) such as the Internet. Note that although one client and one server are shown inFIG. 1, multiple clients and/or servers may also be implemented.

In one embodiment, server102includes, among others, a package builder104and metadata manager105. Package builder104is configured to build (e.g., compile and/or link) and manage packages106that can be downloaded by client101for installation at client101. A package is a single file that is a compressed tree of the files (e.g., binary files), which are compiled from a variety of source codes of a variety of programming languages. Once a package is built, according to one embodiment, the metadata manager105is configured to scan each file contained in the package and add certain metadata to the package. The added metadata includes information indicating a particular application program that should be used to open the associated file, such as, for example, “package foo needs package OpenOffice™ to work correctly” or “package foo can open text files”, etc.

The added metadata is typically added to a header of the package, such as, for example, the package file200as shown inFIG. 2. Referring toFIG. 2, package file200includes a file header201and body202. File header201includes metadata203indicating that the file having the file header201requires the OpenOffice™ with at least version 2.0.0 in order to open the file. The file header201also includes metadata204indicating the mime type associated with the file. File body202includes all the individual files contained in the package200. As a result, when a file hander attempts to open the corresponding file, the file handler can determine the mime type of the package and knows which application program is required to open the package.

Referring back toFIG. 1, the package200can then be stored in a storage device associated with server102as a part of packages106. In addition, metadata manager105is configured to scan each of the packages106and to extract all the metadata from the packages106(e.g., “requires: openoffice>2.0.0”) and all that data is saved to a metadata as a part of metadata107in a storage device. A metadata may be an extensible markup language (XML) compatible data file. This metadata file is relatively small compared to the size of the packages as it does not contain all the file content data; it just contains all the text metadata. The metadata file is compressed and the file is saved in a storage device as a part of metadata107.

Client101includes one or more applications108communicatively coupled to a file handler112, which provides an application programming interface (API) to access one or more files113. When application108attempts to open a file via file handler112, if file handler112cannot recognize the file that is being opened, the file handler112invokes a package installer109to download one or more packages110and/or the associated metadata111from server102over network103. The packages110include an application program or utility tool that is capable of opening the file.

According to one embodiment, when application108attempts to open a file that is not recognizable, package installer109is invoked, for example, to “find me all packages that provide mime-handler (‘plain/text’)”. The package installer109can download the newest metadata file107very quickly from server102because the metadata is relatively small in size. The package installer109then knows about every package (e.g., packages106) available for installation from server102. Package installer109can scan the metadata looking for matches, and return a list to the user of the packages that match the search (e.g., available for installation for opening the unrecognized file).

For example, when a user attempts to open a media file, the package installer determines that an additional media player codec or plug-in is needed based on the metadata associated with the media file. The package installer (in this example, a codec installer) displays, as shown inFIG. 3A, a graphical user interface (GUI) to the user, wherein GUI310includes information identifying a particularly application program, in this example, a Windows™ Media Video 9 decoder is needed. According to one embodiment, at least a portion of the information displayed may be extracted from the metadata.

Similarly, when a user attempts to open a document with an unknown font, the font installer (as a part of package installer) displays a GUI320ofFIG. 3Bindicating that an additional font needs to be installed.

In response to the GUI displayed, referring back toFIG. 1, if the user actually wants to install identified application program or font, the package installer has to match the name of the application program or font to a remote filename using the previously downloaded metadata (e.g., metadata111), and then download the package itself (e.g., packages106). The user can then install the local file at client101. In this way, the package installer can automatically locate the latest or a specific version of required application program or font files from server102and install them at client101. As a result, a user of client101does not need to know which application program is needed for opening a particular file and does not need to conduct a search over the network.

The metadata111stored at the local system can be periodically updated by downloading the newest metadata107from server102onto the local client101, and then search through it to find if any of the remote packages are newer than the ones that have been installed locally. In this way the metadata111is kept up to date. Since the packages and metadata are distributed by a centralized server or servers102, the client101can be sure that the packages downloaded and installed are the latest versions.

FIG. 4is a flow diagram illustrating a method for building packages and metadata for download and installation according to one embodiment. Note that method400may be performed by processing logic which may include software, firmware, hardware, or a combination thereof. For example, method400may be performed by package builder104and/or metadata manager105ofFIG. 1. Referring toFIG. 4, at block401, multiple files (e.g., binary files) are package into a package file, such as, for example, a Red Hat package manager (ROM) file distributed by Red Hat, Inc. of Raleigh, N.C. At block402, each file in the package is scanned and certain metadata is extracted and added into the package, where the metadata indicates a specific application program or tool required to open the respective file or alternatively, types of files that the respective file can handle. At block403, all metadata is extracted from the package and stored in a metadata file. Subsequently, in response to a request from a client over a network requesting metadata, at block404, the metadata is transmitted to the client. In response to receiving a further request for installing a specific tool based on the metadata file from the client, at block405, a package associated with the requested tool is transmitted to the client for opening a specific file that was not recognized by the client.

FIG. 5is a flow diagram illustrating a method for installing packages according to one embodiment. Note that method500may be performed by processing logic which may include software, firmware, hardware, or a combination thereof. For example, method500may be performed by package installer109ofFIG. 1. Referring toFIG. 5, in response to a request from a user to open an unrecognized file, at block501, a request is transmitted to a remote server over a network requesting metadata associated with the file being open. Note that if there is an existing metadata stored locally, the local metadata may be examined first before sending a request for an updated metadata. As described above, the metadata may be periodically updated from the remote server. At block502, a packaging tool is identified that is capable of opening the file based on the metadata received from the remote server or alternatively, based on a local copy of the metadata. The packaging tool may be identified by matching metadata extracted from the unrecognized file and the metadata stored in the metadata file. At block503, a GUI is displayed to the user requesting whether the user desires to download and install the required packaging tool. In response to an input received from the user via the GUI, at block504, the identified packaging tool is downloaded from the server and installed at the client locally. At block505, the packaging tool is launched in response to a user input.

Processor802represents one or more general-purpose processors such as a microprocessor, a central processing unit, or the like. More particularly, the processor may be complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processor802may also be one or more special-purpose processors such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processor802is configured to execute the instructions830for performing the operations and steps discussed herein.

The computer system800may further include a network interface device822. The computer system800also may include a video display unit810(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device812(e.g., a keyboard), a cursor control device814(e.g., a mouse), and a signal generation device820(e.g., a speaker).

The data storage device816may include a computer-accessible storage medium824(also known as a machine-readable storage medium or a computer-readable medium) on which is stored one or more sets of instructions or software (e.g., packaging tool830, which may be implemented as part of package installer109, package builder104, and/or metadata manager105) embodying any one or more of the methodologies or functions described herein. The packaging tool830may also reside, completely or at least partially, within the main memory804and/or within the processor802during execution thereof by the computer system800, the main memory804and the processor802also constituting machine-accessible storage media. The packaging tool830may further be transmitted or received over a network via the network interface device822.

The modules828, components and other features described herein can be implemented as discrete hardware components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices. In addition, the modules828can be implemented as firmware or functional circuitry within hardware devices. Further, the modules828can be implemented in any combination hardware devices and software components.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “identifying” or “displaying” or “downloading” or “receiving” or “invoking” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Embodiments of the present invention also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable medium. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium (e.g., read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices), etc.