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> tag?
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 of thing.
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 urn:mozilla:gecko:plugin:content-type:image/gif 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: <object data="baboon.gif" classid="urn:mozilla:gecko:plugin:content-type:image/gif"> </object> As far as Gecko browsers are concerned, the above declaration would be identical to <object data="baboon.gif" type="image/gif"> </object> Of course, particular plugins may wish to register their own URNs: urn:acme:anvil urn:acme:anvil-2.0 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> </object> Does this look like it will fit into the URN usage framework under consideration?
Changing summary to more accurately describe the problem (rather than a particular solution).
Summary: Plugins should be instantiated via their CID → Need to support multiple plugins for a given content type
Off the top of my head, I'd make the as follows: urn:inet:mozilla.org:gecko:/plugin?content-type=image/gif assuming that "-" is legal in parameter names, and "/" in parameter values. 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 like <object data="foo.data" classid="clsid:ee8c31ab-ccdf-4bef-8da3-417406436223"> </object> 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.
Depends on: 36666
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.
Target Milestone: --- → Future
this will be covered by the plug-in manager work
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Status: RESOLVED → VERIFIED
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: http://elwood.mcom.com/arun/plugins/first-install-problem.html 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: Win32: New field in version info table and HKLM key in Win32 registry MacOS/UNIX: Return "PLID" as first part of string in NP_GetMIMEDescription
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Summary: Need to support multiple plugins for a given content type → Need to support multiple plugins for a given content type (PLID)
Whiteboard: [ADT1+] [PL RTM]
Target Milestone: Future → ---
*** Bug 138363 has been marked as a duplicate of this bug. ***
Taking PLID bug...
Assignee: av → peterl
Status: REOPENED → NEW
Whiteboard: [ADT1+] [PL RTM] → [PL RTM]
Target Milestone: --- → mozilla1.1alpha
*** 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 2. http://mozilla.org/projects/plugins/plugin-identifier.html 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.
Assignee: peterl → anthonyd
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Marking as Topembed+, as this is required by Gecko 2.0
Keywords: topembed → topembed+
Whiteboard: [PL2:P2][Plid][Plug-in Mgr] → [PL2:P2][Plid][Plug-in Mgr] [ETA Needed]
setting to 1.4 beta, plug-in branch
Whiteboard: [PL2:P2][Plid][Plug-in Mgr] [ETA Needed] → [PL:BRANCH][PLID]
Target Milestone: mozilla1.2beta → mozilla1.4beta
Assignee: anthonyd → peterlubczynski
per topembed+ triage: topembed-, Future
Keywords: topembed+ → topembed-
Target Milestone: mozilla1.4beta → Future
Assignee: peterlubczynski-bugs → nobody
QA Contact: shrir → plugins
Based on my understanding of this bug, this is WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 17 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.