A New Plugin Wizard (Re: a bug in default .mozconfig)

[Alexander Sack]

On Fri, Aug 17, 2007 at 11:12:34PM +0200, Giuseppe Scrivano wrote:
> Hello,
> 
> Alexander Sack <address@hidden> writes:
> 
> > The server answer has a licenseURL field ... which we could fill in for
> > all apt results ... flashplugin nonfree has that licenseURL set
> > properly as the plugin finder wizard must display it ... and afaik
> > that is the only plugin available in mozillas database for linux :).
> >
> > Anyway, adding new fields to the result (which is RDF) is possible
> > without breaking the official plugin finder wizard ... so in case we
> > cannot reuse the licenseURL field, we could easily introduce something
> > new.
> Yes, probably adding a new field will be easier for us to handle, now
> the only issue is how handle different way to install plugins, your
> modified version uses apt internally (from what I understood) to
> install them but we need a more generic way to install them. 

The problem with "generic" is that if you don't get them from your
distribution, they mostly don't exist in a universal binary form for
linux ...

If such binaries would exist, we could use the existing XPIInstall
mechanism anyway.

Here a list of (automatic) install mechanisms I have in mind ...

Profile/Generic:
 * XPIInstall - already exists (profile)

Global/Distribution Specifc
 * APT - debian packages from distribution
 * YUM - rpm packages from distributions (obviously I have no idea what
         i am talking about here, because I am an rpm illiterate)
 * TGZ - bsd packages from distribution

( * RPM - rpm packages in the wild
  * DEB - debian packages in the wild)

But given the not-existing-universal binary issues pointed out above I
am unsure about the use-cases of those "in the wild" variants ...

> 
> How does your plugin finder work without break the original one?  Does
> the server always return an URL to a .deb file?

More or less yes. You could add a URL to a .deb (which would work with
gdebi), or ...

at the moment I add an apt: urls to both fields ... which makes the
original plugin service give up on automatic install, but still
triggers the Manual Install button, which starts whatever application
is registered to serve apt: urls.

But maybe you are right and I should use the apt: url in XPIInstall
and add a direct .deb url to the manualInstallationUrl field, which
would allow to trigger whatever .deb mime-type handler is installed
(in worst case just downloading the deb).

I will think about the implications.

> If the XPILocation (or manualInstallationURL) information is not
> needed to install a debian package then we could use it in the usual
> way.

I am not sure I understand what you mean (I use both, XPILocation +
manualInstallation URL atm). I assume you think about adding multiple
sources for the same plugin to the same result entry?

My current approach wouldn't do that, but would treat each install
source as a separate entry in the plugin database and thus you would
get multiple options in the plugin finder result list (e.g. gnash from
apt + gnash from somewhere else). Otherwise, I don't understand what
you mean ... maybe rephrase. ;).


 - Alexander