Features Download

From: Thomas Leonard <talex5 <at> gmail.com>
Subject: Experimental "app" support
Newsgroups: gmane.comp.file-systems.zero-install.devel
Date: Sunday 13th May 2012 13:51:12 UTC (over 6 years ago)
I've created an "apps" branch in the 0install Git repository with
experimental app support.

Apps work a bit like aliases, e.g.

$ 0install add rox http://rox.sourceforge.net/2005/interfaces/ROX-Filer
$ rox --version
ROX-Filer 2.11

The main difference is that apps store their current selections (in
~/.config/0install.net/apps/rox/selections.xml in this case). This
means that they start faster, because the solver isn't needed:

$ 0alias rox-alias http://rox.sourceforge.net/2005/interfaces/ROX-Filer
$ 0install add rox-app http://rox.sourceforge.net/2005/interfaces/ROX-Filer

$ time rox-alias --version > /dev/null
rox-alias --version > /dev/null  0.12s user 0.02s system 91% cpu 0.144

$ time rox-app --version > /dev/null
rox-app --version > /dev/null  0.06s user 0.02s system 92% cpu 0.082 total

When run, they still trigger a background update if they haven't been
updated for a while, and you can also update them manually:

$ 0install update rox
No updates found. Continuing with version 2.11.

They also remember any restrictions (e.g. --before).

Hopefully apps will address a number of issues:

1. Performance: in addition to the minor speed-up above, being able to
run without using the solver means that the .NET version could avoid
starting Python in the critical path, which should lead to a bigger
speed-up there. And on Linux, we could provide a small C launcher that
avoids starting Python too.

2. Desktop integration: the Windows version already has a concept of
applications which are "integrated" into the environment (e.g. adding
shell commands and menu entries). I think this makes sense. Apps bring
this to POSIX systems too (though currently a single shell command is
the only launcher allowed). Bastian, could we merge these systems

3. Sugar caching: there were some patches to cache solver output on
Sugar for performance, but making sure that the cache was always
invisible (i.e. didn't give confusing out-of-date results in some
cases) was hard. By making the caching explicit, we avoid this

In addition, this kind of mechanism could be useful in a number of
other places (but I haven't worked out how exactly):

4. Roll-back: we store past selections (max one set per day) so if an
update goes wrong you can see what changed and roll-back easily.

5. Services / web-apps: these need an easy way to set and update
selections, possibly with no automatic updates at all in some cases
(often you only want to update when the admin is present).

6. Having the applications all in one place means we can list all the
apps easily, which we can't do for aliases. It might also make it
easier to decide what to remove from the cache. However, it's also
less flexible. Should we support apps in custom locations?

7. It may be possible to store other configuration inside an
application (as e.g. ebox does). Need to think more about this,
though, because it affects how you connect programs together. There
might also be a link with the ROX app-dir launchers.

Probably this won't go in 1.8, but feedback welcome...

Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Zero-install-devel mailing list
[email protected]
CD: 12ms