- in case of issues, we have a few options: * remove the code that tries to install a package associated with an integration script that has been found to be "available but not installed" (i.e. a package exists for it) for a given URL, the code would be removed w/ a low & controlled risk from the chromium and firefox extensions, * in libunity-webapps-repository, when searching for an available integration script for a given URL, two "sources" are being considered: scripts that are found locally (already installed previously using the installation process described above, or installed through a package such as lp:webapps-applications with an --enable-applications=yes flag), and scripts that are "installable" e.g. found in apt-cache as WebApps packages and for which an "installation" process can be launched. The two sources can be considered in that order and can therefore be disabled individually there: http://bazaar.launchpad.net/~webapps/libunity-webapps/trunk/view/head:/src/libunity-webapps-repository/unity-webapps-application-repository.c in the function unity_webapps_application_repository_resolve_url, - the code can be browsed in src/libunity-webapps-repository and src/index-updater http://bazaar.launchpad.net/~webapps/libunity-webapps/trunk/files/753/src/libunity-webapps-repository and http://bazaar.launchpad.net/~webapps/libunity-webapps/trunk/files/753/src/index-updater (see breakdown below), - since there seem to be some (legitimate) confusion about how it works here is a quick walk-through (sorry for the length): Part of the WebApps technology, integration scripts that expand the "scope" of a given website (URL) are being "run" along with a given webpage by dedicated extensions (for chromium and firefox). Those scripts (small snippets of code, a few 10s of line of code) basically create a bridge between selected elements of the desktop (currently messaging indicator, launcher, sound menu, hud, notifications) and available resources in the website itself. We have a current set of default scripts (around 40), the idea is to allow the community to also participate to the effort and contribute to new integration scripts. The integration scripts will be made available as individual packages (deb) each one containing a set of icons, some doc, and the core javascript file itself. They will be made available through our repos (after going through a very strict review phase). Along with each integration script, a manifest file ("manifest.js") will also be found that declares a set of descriptive meta-information about the WebApp itself: a glob friendly URL for which it should be triggered as an integration point, a homepage for the application, names of icons associated with the application (installed), a description, various version numbers, etc. Now, coming back to the core functionality itself. When a website is being visited (URL), the libunity-webapps-repository lib is being queried by the corresponding browser extensions to check whether an integration script is associated to it. The entry points for the query itself are located in the "unity-webapps-application-repository.c" file in the unity_webapps_application_repository_resolve_url() function. This function searches first locally to check if a given integration script exists for the associated URL (through the manifest meta file) and, in the case of a negative answer, extends the search to packages marked as WebApps packages that can has been found in apt-cache's output (described a bit further). If an installed integration script is being found, its content is being returned by the unity_webapps_application_repository_get_userscript_contents() function to the extension. In the other case, if a script has been found as an available but not installed package, the extension tries to install it with unity_webapps_application_repository_install_application. Most of the files in the libunity-webapps-repository folder, deal with parsing the manifest file (meta informations about a Webapp useful for the extension), handling the installation of the deb package associated with an WebApp application of interest, load the content of the javascript file (and its potential requirements e.g. other common/helper javascript files), probing the available apps (either locally or in packages) for one that would match (glob) the current URL, etc. Each of the WebApp have an associated state with it AVAILABLE, INSTALLED, etc. that can be used to further act upon it. One missing piece is the retrieval of the available (but not installed) packages found. Each WebApp will be an individual package available from our repository (after a thorough review process). The generated .deb file will contain some additional tags that informs any external player of some meta data related to it: the integration point it is associated with (URL glob), its homepage, etc. Here is an example of the debian/control file associated with one such package: Package: unity-webapps-angrybirds Version: 2.2 Architecture: all Maintainer: Webapps Team