rvj wrote: > > Apologies - I was thinking out loud .The aim is to have a parent > installation script > > What I would like to be able to present a list of packages/components for > installation from a specific website and allow the user to choose which to > install or reinstall.
Something like Netscape's "SmartUpdate" site for 4.x? Mozilla (and N6) users are re-directed to Netscape's regular download page, but you could use 4.7x on Mac or Windows to get an idea what's possible. > Instead of opening a remote xpi file, I would like to be able to let users > to open a remote xul window which will allow the user to choose what > packages to install from that site. XUL or HTML, this can be done. When the use has finished choosing then use the InstallTrigger.install() command to launch multiple packages at once, with a single confirmation dialog. > On the assumption that installation security depends on where you are > downloading from, I cant see that opening a remote XUL window rather than a > remote XPI file is a security problem. Remote XUL has no more privileges than remote HTML because users can stumble across sites accidentally or be redirected. Users are *asked* before being given an XPI file, they don't get asked before loading each page. > So assuming the remote XUL window displays a list of packages available on > that site, the user can select one or more and the XUL script can issues > calls to a package installation or deinstallation routine. Uninstall has not been implemented, but otherwise this can be done. > The real problem as I see it is that some of the functions of the current > install.js script need to be performed by the parent XUL window script > disc space calculation to name an obvious case) so some of the xpi commands > should also be callable through the XPCOM interface That's where things get tricky. What, exactly, do you want to be able to do on the site side? How do we balance the privacy issues? Disk space *is* the obvious case -- are there others? -Dan Veditz
