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. 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. 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. 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. The solution (which I think you are suggesting) is that the XUL window has a callable XPCOM interface. The XUL installation window buttons could be used to capture install/deinstall/cancel request and pass them on to the embedded XPI interface. The main XUL scripting requirements are a) identify the package(s) b) select whether for installation/deinstallation c) start and cancel events 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 > > The xul window would contain the xpinstall script rather than being embedded > > in the xpi package? > > > Didn't follow the last bit at all, but as to the first part, no, we'd never > let this be customized. Installing something is supremely dangerous, once > you get something on a victim's disk you've one. We can't take a chance that > someone would "customize" the install dialog to look like it's something > else entirely. > > I am starting the work to make XPInstall embeddable, which will allow the > install UI to be overridden by an XPCOM service--but you'd have to install > that service first, and it would from then on provide the UI for all installs. > > Do you have completely different needs, or do you just want to improve > what's there? We can certainly improve the Mozilla UI (and in fact are > thinking about ways to do it). > > -Dan Veditz >
