Re: [Plash] Zero-install and Plash

[Mark Seaborn]

[This is about using Plash and Zero-install together.  I'm CC'ing this
to cap-talk because there are a couple of points on the
Polaris/CapDesk "pet" installation models that people on cap-talk
might want to comment on.]

Thomas Leonard <address@hidden> wrote:

> On 7/18/06, Mark Seaborn <address@hidden> wrote:

> > I guess the default file associations would need to be set up a
> > different way?  e.g. Have a way of instantiating a bunch of
> > applications at once.  This would only be an issue when installing ROX
> > on an existing desktop; a newly-installed desktop could instantiate
> > the defaults when you create a user account.
> 
> You want to link to the defaults rather than copy them. E.g., if I add
> additional associations to ROX-Defaults (say, that clicking on an svg
> file will download and run Inkscape) then users should get that
> association on their next update.

I see what you want to do.  I'm not sure how well it would fit into a
pet system like Polaris and CapDesk use.  The idea behind those
systems is to make sure that the user is aware of the applications
they are installing and what authority they have.  Pet names must be
chosen by the user, and are displayed in window titles, so that the
user can tell what they are trusting their data to.  Installing
applications by default, and having a dynamically changing default,
would seem to defeat this.

I can think of two ways a system could handle default file
associations:

1. Double-clicking a file with a type that is associated with a
default application starts the instantiation process for that
application, allowing the user to choose a pet name, etc., after which
the application is launched to open the file.  The problem with this
is that it is too much like a confirmation dialogue box, and the user
might just click "OK" without looking.  It is not clear what the
source of the application was.

2. The instantiation happens as late as possible.  The default
application is run when the file is double-clicked, but it is not
given access a configuration directory.  When the application needs to
save config options, it can ask to be instantiated properly; until
then, it cannot save state between sessions.  But this also means it
does not get assigned a pet name before being instantiated.


It seems that having dynamically-changing default file associations
violates "up front"-ness.  You can't review the defaults at your
leisure.  You find out about them too late, when you double-click a
type of file not previously used, and get a dialogue box for
instantiating an application.

That brings me back to the idea of a "bulk install" feature for
instantiating several applications at once.  This could suggest
applications that are not already installed while leaving out those
that are.


> > The full answer to these problems is to have a persistent
> > object/capability store.  In such a scheme, an application instance
> > would be an object with references to objects it has been granted
> > (such as its configuration directory).  The application would be able
> > to store futher capabilities that it has been granted (e.g. via a
> > powerbox or drag-and-drop) and retrieve them later, including after a
> > reboot.  Similarly the user's Start menu (or similar) would contain
> > references to applications' executable objects.
> 
> I don't quite understand how this helps. Why does an application that
> has been allowed to write a file once get to keep this ability
> forever, even over reboots?

Some programs need to keep authority in the long term.  For example, a
music player maintains a playlist and its references to MP3s should be
read-only and persistent.

I suppose the file powerbox could have an option "Grant for this
session only".  When not selected, we grant the file/directory
persistently and the access is not revoked when the application's
windows are closed.  Whether this option is selected by default could
be set on a per-application basis.  You would have it set by default
for editors, but not for music players.

Cheers,
Mark