Plugin Identifier Specification
Contents
Plugin ID Definition
A Plugin ID (PLID) is a string in URI format that identifies a plugin
uniquely.
A PLID takes this format:
@Domain/ProductName,version=[?versionInfo&versioninfo=],*[ModuleIdentifier]
The special symbols are @, / and ,. A PLID begins with an @Domain, followed
by a "/", then a ProductName, a "," (comma) and version=version number.
The PLID is a unique identifier for plugin modules, and on Win32, form the
basis for registry keys (see First Install
Problem write-up).
Key To Above Definition
* -- Optional -- Zero or more can be present? -- One or more are required
[string] -- Vendor determines the pattern the *string* may take
Breakdown of a Plugin ID (PLID)
- Mandatory: @Domain
The @Domain part of the PLID can consist of a '@' symbol and a Domain Name (e.g. @netscape.com or @mozilla.org). Domain Names are generally unique, and are a suitable means to identify the parent company that makes the plugin. An example might be @application.com. But the @Domain does not necessarily have to be a domain name. It can be any string, so long as it follows URI convention. Another example: @musiccomponent.made.by.john . We leave it to the vendor to decide whether to use a domain name (in URL style) or some other identifier. See the section on Domain Name Concerns - Mandatory: ProductName
After the "/" separator following the @Domain, the ProductName is a string identifying the product in question. Examples could be MusicPlayer or ReallyOne Player. Since the @Domain and the ProductName are the only two mandatory pieces of information, a valid PLID might be @snappy.com/FastTime Player - Mandatory: version=
A "," (comma) separator following ProductName is used before version. Version is the vendor-determined versioning mechanism.
Examples:- version=5.0.0.1
- version=5&Minor=0.0.1
- Optional: [ModuleIdentifer]
A PLID is bound to a specific module. But if one application consists of several DLLs, each which handle their own mimetypes, then more than one PLID may be necessary. An example of one "real world" application with more than one DLL for Windows is QuickTime. each QuickTime DLL handles its own mimetype(s). If, for example, an application has 5 DLLs which handle 5 mimetypes, then that application would have 5 PLIDs. The ModuleIdentifier is just a Vendor-determined string, and can take any form. A "," (comma) separator follows the version token if the use of ModuleIdentifier is made. Here are some suggestions:
Examples of more than one PLID for one application:- @snappy.com/FastTimePlayer,version=5.0.0.1,MPEG1 where MPEG1 is the ModuleIdentifier, suggesting that this DLL will handle MPEG1 file format.
- @snappy.com/FastTimePlayer,version=5.0.0.1,application/x-fasttime where application/x-fastttime is the ModuleIdentifier, suggesting that this module in the FastTime package handles the mimetype application/x-fasttime.
Domain Name Concerns
A legitimate concern with using domain names bound to real-world URLs might be that companies change, e.g. Company A buys Company B and alters the copyright dynamics of Company B's name. Vendors who wish to insulate themselves from this may choose alternate nomenclature (example: @musiccomponent.made.by.john .
Future Directions
Embedders such as CompuServe (who now embed Gecko in lieu of IE as the default browser) can determine on their own the mechanisms to parse the Win32 registry for PLIDs. The Bugzilla bug open on Mozilla and Netscape 6.x is Bug 138363.
Ultimately, the goal is to see this idea work in the context of usage of classid with the OBJECT tag to invoke particular components, instead of arbitrary mimetype-based resolutions. If every major plugin vendor complies with the writing of plugin directory
information into the registry along with a PLID, we can then use the OBJECT
tag to invoke plugins based on their "classid" (their respective PLID, which
is a URI, which works well with the W3C
HTML 4.01 specification for OBJECT). For example, in our case, a prospective
invocation might look like:
<object classid="@mycompany.com/MyApplication,version=5.01" data="myfile.typ"
codebase="http://myurl.com/myplugin/myplugin.xpi" type="application/x-myapp">
</object>
The use of both "type" and "classid" attributes here offers the following
user benefit:
- IF there is another mimetype handler for application/x-myapp, ONLY MyApplication gets invoked. The resolution of a mimetype handler is no longer arbitrary.
- IF the "data" file myfile.typ doesn't contain enough resource information to load the correct mimetype handling component (DLL), specifying "type" is an additional mechanism.
- Unlike UUIDs, PLIDs are human readable.
Contact aruner@netscape.com with any further questions.