FirefoxNspluginwrapperSpec

Differences between revisions 3 and 4
Revision 3 as of 2007-06-13 10:04:51
Size: 3885
Editor: e177172213
Comment:
Revision 4 as of 2007-06-13 10:43:50
Size: 5084
Editor: e177172213
Comment:
Deletions are marked like this. Additions are marked like this.
Line 35: Line 35:
=== Status Quo ===
Line 43: Line 45:

=== Status NEW ===

In order to allow the use of nspluginwrapper, packages should still install their native 32-bit plugin library to $pkglibdir, e.g. {{{
/usr/lib/flashplugin-nonfree/libflashplayer.so
}}}

On 32-bit hosts plugins should ship a link for their plugin library in $pkgvardir, e.g. {{{
/usr/lib/flashplugin-nonfree/libflashplayer.so /var/lib/flashplugin-nonfree/libflashplayer.so
}}}

In contrast, on 64-bit hosts plugins should create the nsplugin wrapper library in postinst to $pkgvardir, e.g. {{{
nspluginwrapper -c -i /usr/lib/flashplugin-nonfree/libflashplayer.so /var/lib/flashplugin-nonfree/libflashplayer.so
}}}, which will create a 64-bit plugin wrapper for the 32-bit library installed in {{{/usr/lib/flashplugin-nonfree/libflashplayer.so}}}

Now, deployment of the plugin doesn't point to the native 32-bit library directly anymore, but instead point to the $pkgvardir contained library, which is either a link or a 64-bit plugin wrapper, e.g. {{{
/var/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/mozilla/plugins/libflashplayer.so
/var/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/firefox/plugins/libflashplayer.so
}}}

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

  • Launchpad Entry: firefox-nspluginwrapper

  • Packages affected: nspluginwrapper ubuntu-desktop [amd64] flashplayer-nonfree

Summary

AMD64 is an important architecture for desktop linux; in consequence a good proportion of users lack the ability to use third party/proprietary plugins for firefox which usually are only available for i386 architecture only.

NsPluginwrapper tries to overcome this by interfacing the 64bit and 32bit world.

Release Note

Users of 64-bit firefox should be able to install 3rd-party (32-bit) plugins for firefox out of the box. In consequence we are now able to ship 3rdparty 32-bit firefox plugins as amd64 packages as well.

Rationale

The lack of proprietary firefox plugins on amd64 contributes negatively to the web-experience of amd64 ubuntu users.

Use Cases

  • Play Flash content that cannot be properly processed by free flash alternatives
  • Use Java Applets that don't work on free java plugins

Assumptions

This specification cannot assume that plugin libaries are available during build time. For example, the flashplayer-nonfree package doesn't ship the libflashplayer.so, but instead downloads it during install from the adobe website.

Design

nspluginwrapper basically allows to create a wrapper plugin that bridges 64-bit and 32-bit worlds.

Status Quo

Currently plugins that implement the nsplugin API don't install the plugin binary directly in the firefox plugins directory, but put their library in $pkglibdir/ (e.g. /usr/lib/flashplayer-nonfree/).

In the past, this best practice evolved in order to make plugins available to multiple mozilla installs without the need to duplicate the plugin binaries in multiple places. The links however are usually created inside the package at build time (e.g. by using dh_link). Example taken from debian/links file of flashplugin-nonfree source package:

/usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/mozilla/plugins/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/firefox/plugins/libflashplayer.so

This specification makes use of this established practice and adapts it according to our needs ...

Status NEW

In order to allow the use of nspluginwrapper, packages should still install their native 32-bit plugin library to $pkglibdir, e.g.

/usr/lib/flashplugin-nonfree/libflashplayer.so

On 32-bit hosts plugins should ship a link for their plugin library in $pkgvardir, e.g.

/usr/lib/flashplugin-nonfree/libflashplayer.so /var/lib/flashplugin-nonfree/libflashplayer.so

In contrast, on 64-bit hosts plugins should create the nsplugin wrapper library in postinst to $pkgvardir, e.g.

nspluginwrapper -c -i /usr/lib/flashplugin-nonfree/libflashplayer.so /var/lib/flashplugin-nonfree/libflashplayer.so

, which will create a 64-bit plugin wrapper for the 32-bit library installed in /usr/lib/flashplugin-nonfree/libflashplayer.so

Now, deployment of the plugin doesn't point to the native 32-bit library directly anymore, but instead point to the $pkgvardir contained library, which is either a link or a 64-bit plugin wrapper, e.g.

/var/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/mozilla/plugins/libflashplayer.so
/var/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/firefox/plugins/libflashplayer.so

Implementation

( This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: )

UI Changes

( Should cover changes required to the UI, or specific UI that is required to implement this )

Code Changes

( Code changes should include an overview of what needs to change, and in some cases even the specific details. )

Migration

( Include:

  • data migration, if any
  • redirects from old URLs to new ones, if any
  • how users will be pointed to the new way of doing things, if necessary.

)

Test/Demo Plan

( It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.

This need not be added or completed until the specification is nearing beta. )

Outstanding Issues

( This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. )

BoF agenda and discussion

( Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. )


CategorySpec

FirefoxNspluginwrapperSpec (last edited 2008-08-06 16:15:19 by localhost)