> > 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 other?
A lot depends on whether you think a XUL/XBL implementation of xpinstall
is likely.
Your first reaction was that you would not consider permitting customised
installation dialogs but as I suggested in later post in the same thread,
making the core functions available as explicit XUL/XBL elements should meet
any security concerns. It only allows users to position and style the
appropriate installation buttons using standard css stylesheets For
example,
install { background-color:red; width:60px; height:40px;position:absolute ;
top:100px; left:100px}
cancel { background-color:red; width:60px; height:40pxposition:absolute ;
top:100px; left:200px }
If, for example, there were a packages.rdf that could be picked up from a
web site as a datasource to an <config/> widget,
then most of the info required for installation purposes could be extracted
from packages.rdf including the xpi filename
<config src="http://www.mozilla.org/installation/packages.rdf "/>
If <install/> were based on or inherits a <tree /> element, then the UA
designer can choose what info to display For example there is little point
in displaying the xpiFilename but displaying the packageName and
Packageversion is much more useful.
More importantly the package attribute can be extended.
A package description in packages.rdf might look like :
<RDF:Description
PACKAGE:packageName="xyz"
PAGKAGE:packageVersion="1.1.1."
PACKAGE:packageAuthore="Mozilla.org"
PACKAGE:xpiFilename="xyz.xpi"
PACKAGE:xpiFilesource="http://www.mozilla.org/installation "
PACKAGE:xpiFilesize="1.2"
/>
So given the package definition above, it is not necessary to get the xpi
filename, location, filesize, etc from an install script. These can simply
be extracted from a package description
Things such as calculating the disc space required can be done quite simply
from the xpiFilesize value and and determining space available on the
current machine using standard js script io functions
What I really think Im getting at is the need to separate the package
description from the installation script.
Im off till the new year so happy whatever but I'm interested to find out if
anyone else is thinking along similar lines.
