- 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 <weba...@lists.launchpad.net>
Installed-Size: 136
Depends: unity-webapps-common, xdg-utils
Section: web
Priority: extra
Homepage: http://chrome.angrybirds.com
Ubuntu-Webapps-Includes: http://chrome.angrybirds.com/*
Ubuntu-Webapps-Name: AngryBirds
This has been generated part of the deb package.
A WebApps specific DB (sqlite) found in the users local folder
(~/.local/share/unity-webapps/) will contain an up-to-date list of
available WebApps packages along with its associated URL (integration
point). This is what will be queried by the part of the code responsible
to check if a WebApp is available (but not installed). For each entry,
it contains the package name and the URL(s). You can see it in src
/unity-webapps-app-db.[ch]. When necessary, the package name will be
used to trigger the installation of the package.
This database will be updated periodically by a standalone executable
that can be found in src/index-updater. It will be responsible for
calling "apt-cache", parsing its output searching for WebApp specific
packages (that contain the proper tags), and updating the DB based on
this. The code in src/index-updater/apt-cache-parser.[ch] is reponsible
for parsing the output of apt-cache.
** Changed in: libunity-webapps (Ubuntu Quantal)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1043461
Title:
[FFE] Update WebApps to support dpkg distribution mechanism
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunity-webapps/+bug/1043461/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
