On May 14, 2013, at 02:37 PM, Colin Watson wrote:
>> > Barry spent
>> >some time looking at 0install, and it wasn't too bad a fit but we would
>> >still need to solve many of the same system integration problems.
>> Is there a list of these issues somewhere?
>Barry Warsaw would have to speak to that, I think. But mainly, there's
>no way for the system to declare any kind of integration facilities at
>all, as far as I can see, so we'd have to solve that problem anyway.
What I think Colin is getting at here is that any system is going to have to
deal with declaring the files that allow an app to interoperate with system
services. Think along the lines of dbus .service files, .desktop files, etc.
These will be things we might know about right now (such as the above), but
they maybe be additional integration points in the future.
Let's say for example, some future system service comes with a new version of
the SDK or OS image, that allows apps to define push notifications, by
including a .push file that has to get installed somewhere to be registered.
The app itself will only declare that it has a myapp.push, and you won't have
anything like a maintainer script to install myapp.push. Instead, the
system's push notifier will have to be responsible for registering a plugin
with the installer system to say "okay, now when you see .push files, put them
here and do this something to register it."
You don't want the logic for that in the installer, and you don't want it in
the app. You want it as part of the system push notifier. This latter will
register a trigger that gets run whenever the installer sees that an app has
declared a .push file *and* you want it to run over all app .push files when
the system push notifier is installed. In the latter case, imagine that you
have a dozen apps that support push notifications installed on your phone, but
the system push notifier hasn't been installed yet. Once it is, all your
already installed push-enabled apps will Just Work.
This all means that the installer must have plugins for handling new
functionality and the declarative manifest must be extensible, i.e. the
installer will ignore extensions that it doesn't (yet) have a registered
I didn't get far enough on 0install (or don't remember ;) whether it has that
>I will certainly concede that the rest of 0install is very flexible and
>has a usefully pluggable design; you seem to have done a good job on it
>and Barry spoke well of it. It just seems that there's a bit of a
>mismatch in that it's kind of over the top in terms of flexibility for
>what we need and seems to be entirely missing some other things we need,
>as above; and it would be a lot of code to rewrite in some other
>language if (as is possible, though not imminent) we decide that Python
>is just too heavyweight to run routinely on the Ubuntu phone.
On just few other points:
I'm not really a big fan of XML formats, since they're not human consumable
(readable or writable). Others may disagree, which is fine, but I don't have
any interest in arguing about it. Probably not a deal breaker, since the XML
files can always be generated, either by the 0install tools or something that
takes a JSON or YAML as input, etc.
I liked that it was fairly easy to wrap executables in "security" containers,
but I didn't dig into this in a lot of detail.
It seemed to have good security considerations.
IIRC, there's no built-in support for uninstallation.
We probably want something like an online-only search REST API for finding
apps, and then downloading from the URL such a search gives us. Thus, there's
no cleverness in the repository layout, nor on the device, for finding apps.
Anyway, that's about all the additional stuff I've gleaned from my previously
private experiments with 0install that hasn't already been discussed in this
P.S. If we *were* to accept that the installer could be written in Python, it
would *have* to be Python 3. No more Python 2 on the phone, please!
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel