Right now, plugins are instantiated via their progID (which is parameterized
based on the MIME type served by the plugin). There is the obvious problem of
having multiple plugins which can view the same content type(s), but even in
general the progID does not offer a sufficient guarantee of uniquess.
Plugins should be instantiated via their CIDs.
(I know there has been some talk of using URNs for progIDs; but do we really
want to *require* that all components have progIDs? In other words, do we want
to require that all component providers register in the URN namespace?)
How would this affect content?
Would all content that uses plugins have to be modified for rendering in
mozilla/nn6? That is, would a plugin CID have to be specified in an <embed>
IE handles this by having a notion of a default plug-in for a given content
type--the default is the last one to register for that type. A *specific* plugin
can always be referenced using the CLASSID attribute of OBJECT.
Most content would not need to change, since most content shouldn't care about
what particular plugin is used to view the content.
rayw: Do you think we could ape IE here? I see substantial advantage to this:
(1) Content developers are already familiar with this mode of operation in IE.
(2) If plugin developers can use the same UUID for their XPCOM and COM plugins,
then supporting both browsers in content becomes simpler.
The only substantial weakness I perceive in IE's scheme is that the browser
provides no UI for a plugin to reassert its registration (making that plugin the
default for the content type it views). It leaves this to the individual plugins
to implement, and most don't. Mozilla ought to provide a UI to manage this sort
I should clarify: this wouldn't *impose* any change on content. Right now,
content has to just deal with whatever plugin a user has installed for a given
content type. Content that didn't change would continue with that scheme, using
the default plugin (as designated by the user).
What I'm proposing would give content providers the flexibility of specifying a
particular plugin for a content type.
There is another complication here that has occurred to me. In my experience
with ActiveX plugins in IE, the clsid used in the OBJECT tag does not change
from one version of the plugin to the next. I think this is a Good Thing: as a
content provider, I don't want to be demanding an older version of a plugin on
my page when the user has just installed a perfectly usable new version. We need
some kind of version-independent CID for plugins.
I believe that we do not want to move to a versionless CID.
We intend to eliminate progids and use capabilities instead using URNs, which
can take a variety of forms.
The capability scheme we are looking at:
1. Solves common versioning problems not solved by versionless progids or CIDs.
2. Allows for parameterization.
3. Would permit us to create a space for randomly-generated numbers underneath
mozilla for any developers who were somehow unable to come up with a
more-appropriate capability name.
rayw: I generally like the idea of using URNs for this stuff. But how exactly
will the URN scheme under consideration assist solving the problem here?
Primarily, a means of identifying a particular vendor's plugin is needed.
Secondarily, a means of identifiying a particular version of that plugin is
needed (see bug 1776).
More thinking on this...
Assuming the parameterized URNs will work more or less the same as parameterized
progIDs work now, the "default" means for instantiating a plugin could be via a
"mozilla.org-owned" URN. For instance
This identifer would refer to the user-designated default plugin for GIF images.
Plugins wouldn't ever have to know about it--they'd just register as supporting
a content type. But if an application wanted this arbitrary GIF plugin, this URN
is how they'd refer to it. This could even happen in an OBJECT element:
As far as Gecko browsers are concerned, the above declaration would be identical
Of course, particular plugins may wish to register their own URNs:
The first of these is version-independent, and a page developer could invoke
whatever version of the Anvil plugin a user has installed like this:
<object data="coyote2" classid="urn:acme:anvil"></object>
Of similarly, version 2.0 of the plugin could be invoked with
<object data="coyote" classid="urn:acme:anvil-2.0"></object>
Getting a little fancier, say I have content that uses the on-the-fly
gravitational inversion feature of Anvil that appeared in version 2.0. But I
also have content that can be used with any version of Anvil. The alternate
content facility of OBJECT makes this easy:
<object data="coyote2" classid="urn:acme:anvil-2.0">
<object data="coyote" classid="urn:acme:anvil"></object>
Does this look like it will fit into the URN usage framework under
Changing summary to more accurately describe the problem (rather than a
Off the top of my head, I'd make the as follows:
assuming that "-" is legal in parameter names, and "/" in
I have proposed separating the version into a separate argument so that we don't
need to either separately register all versions or parse urn's everywhere
looking for version numbers. I think that components will develop a large
number of versions as time goes on and streamlining/economizing the treatment of
version numbers and the size of the registry is justified. On the other hand,
we could decide to leave the version number in the capability name and fix
registry performance by other means as that becomes a problem as the number of
capability versions register by each component grows. It certainly makes the
implementation easier, and we have to fix performance of the registry in any
case. The performance will not bite us at all in the beginning.
What do you think?
As you have shown in your example, the vendor registers any generic mozilla
capability he is willing to supply and also any vendor-specific capability he
wants to make available.
Also, the need has been mentioned to support plugin writers with no internet
domain, who would like to rely on random names:
urn:inet:mozilla.org:anonymous:/<any random sequence>
Any vendor can generate a sequence he feels is long enough to always be unique,
which can be numeric, alphanumeric, etc. Vendors which take adequate care in
generating reasonable sequences are not likely to collide with vendors who did
not. Or vendors can use any other urn scheme that exists today or is developed
in the future.
Since this is a urn, you can still add "?version=2.2" register for multiple
versions, parameterize, etc.
A minor clarification on the name I gave above: we probably need to make it
clear that "gecko:" is only used for xpcom capabilities, or prepend "xpcap:" or
something like that to keep these names distinct from any other use of urn's by
gecko that could occur in the future, etc.
I was playing fast and loose with URN syntax. I'm not sure what all the URN
naming rules/conventions are. I'm fairly certain the '/' needs to be escaped in
a Real URN. And I'm a little surprised to see "inet" in a name for a resource
that won't be accessible over the Internet. Of course, I don't really know what
"inet" implies here. Any particular references I should be looking at? (I'm
making my way through RFCs 2141, 2276, and 2611.)
I think it is reasonable to look at the version as a capability. A given
component could register to support multiple versions--for example, a new
version that is 100% backward compatible would register as having all previous
versions as capabilities.
I'm not clear on why this would imply that we'd need always to parse URNs
looking for version numbers--they could be treated like any other capability,
couldn't they? IMO, we need to face that the registry will get Large by some
means or other, and look at means of accommodating that. But I agree that facing
that can be postponed.
Before we stray too much from the topic of this bug, let me make this proposal
for a plan for its resolution:
The CLASSID attribute of object can be used either with a URN identifying an
XPCOM plugin, or the plugin's CID. An example of the latter would look something
Alternately, a URN may used in the CLASSID attribute. At least one URN
corresponds to a plugin; the base of this URN is specified as part of the Gecko
runtime, and it takes as a (required) parameter the MIME content type of the
data to be handled by the plugin. A plugin may support multiple content types,
in which case multiple URNs of this form can invoke it (one URN for each content
type). Multiple plugins supporting a given content type may exist on the system
simultaneously, but only one of those may be registered for that content content
type at any given time. In this context, "registered" means that the plugin will
be invoked in response to notification of a resource's content type, either via
the HTTP header, the TYPE attribute of OBJECT, or a URN of the aforementioned
form in the CLASSID attribute of OBJECT.
A plugin developer may also (optionally) register an additional URN as
corresponding to a plugin. Plugin developers are responsible for registering
these URNs with the naming authority as appropriate. This URN may also be used
in the CLASSID attribute of OBJECT. Depending on capability parameters, it may
invoke an arbitrary or a specific version of a plugin.
In the interest of limiting confusion, I'm going to refrain from too many more
examples with URNs until I understand their syntax (and how mozilla.org intends
to apply it) better. But let me know if an example is needed for further
clarification here, and I'll see what I can do.
This all speaks to what Web developers see, and not much to the actual
implementation. That part is not all that clear to me, and probably won't be
until I get a better understanding of the intended usage of URNs. I understand
that the finer points of that are still being fleshed out. To that end, I'm
adding bug 36666 as a blocker for this one.
I think I agree with most things you said. I believe I have convinced myself to
just put the version in the URN. The only reason to do differently is if you
have frequent rereleases with new version numbers and don't like all those
distinct capabilities piling up, separating out the version allowed us to
compress the registration and resolution. We can always add that later if it
becomes obvious that it is necessary.
urn: is intended to be a fairly diverse space, with lots of different schemes
(NIDs? -- it has been a few weeks since I read as many specs as I could find, so
I am forgetting the correct terminology). I believe that it is not proper to
just make things up right after the urn: protocol. You will find documentation
on a variety of NIDs.
One such NID is inet:, which, I believe, allows any owner of an internet domain
to identify the domain, and then make up his own sub-schemes. It is inaccurate
to say that the component either will or will not be retrieved over the
internet. Being a urn, a variety of retrieval mechanisms might be used, but the
urn only serves to identify. As I understand it, inet: simply means that we
rely on the internet domain registry to ensure the uniqueness of the next part
of the urn, rather than relying on some other registration technique.
Different bodies have worked on different aspects of urn's. I couldn't find a
crystal-clear place where it was all described together, but I think what I
have demonstrated is close.
Not a Netscape 6 RTM blocker. FUTURE. This bug has been marked Future because
the Netscape engineer it is assigned to is overburdened.
this will be covered by the plug-in manager work
beppe: How is this covered by the plug-in manager work? I see some conceptual
(and probably implementation) overlap; but this bug is about allowing page
authors to select a *specific* plug-in (as opposed to an arbitrary plug-in for a
specific media type).
part of the plug-in manager work is a new process we are putting into place. We
will be supporting the object tag for plug-ins and part of the support will be
the use of a unique identifier for plug-ins. Please see bug 144244 and bug
144263. The identifier can and will be used by embedding clients and web authors
I am resurecting this bug. This is going to be the "PLID bug" because of all the
good discussion already here.
Copying Arun's comments from bug 138363:
First let me apologize to Mozilla contributors outside the Netscape/AOL
firewall, but I'm going to post an internal link:
When I get back from vacation, I promise to write this up in for mozilla.org on
Mozilla website. But the issue is:
We've decided to create a Plugin ID system in the Win32 system registry that
could be extended to other platforms via a flat file. Gecko needs to parse
these registry entries for plugin information, such as path to module and path
to XPT, in addition to parsing existing plugins directories. Embedders can
determine their search order on their own.
Here's how we can read this info:
New field in version info table and HKLM key in Win32 registry
Return "PLID" as first part of string in NP_GetMIMEDescription
*** Bug 138363 has been marked as a duplicate of this bug. ***
Taking PLID bug...
*** Bug 1776 has been marked as a duplicate of this bug. ***
*** Bug 152729 has been marked as a duplicate of this bug. ***
True to my word, upon returning from vacation I posted the documents to the
public :-) :
1. http://mozilla.org/projects/plugins/first-install-problem.html and also
However, a few things need to be added. As Baden says in Comment 16 , this bug
is about letting web page authors specify what plugin is loaded. This is the
PLID as used in markup, e.g.
<object classid="plid:@unreal.com/unrealplayer,version=8" data="myfile.urm"....
This forces the loading of UnRealPlayer to handle the URM file type (both plugin
and file-format are imaginary for illustrative purposes) in lieu of arbitrary
MIME type collisions. However, we need yet another bug to do the scan of the
Win32 Registry upon startup or plugin load time to add additional directories to
the Plugin Scan. This is a related but distinct problem, and is mentioned in
Bug 159445 .
Arun: Thanks. One issue: adding schemes in the IETF tree is Not Nice. For a
modicum of respect for RFC 2717, "mozilla-plid" should be used rather than "plid".
Baden: these are merely illustrative, and don't *really* correspond to IETF schemes.
Arun: Your illustration *really is* in the IETF name tree. Mozilla has invaded
this namespace before, and I'd just like to avoid it happening again.
batch: adding topembed per Gecko2 document
Marking as Topembed+, as this is required by Gecko 2.0
setting to 1.4 beta, plug-in branch
per topembed+ triage: topembed-, Future
Based on my understanding of this bug, this is WONTFIX.