Closed
Bug 99158
Opened 23 years ago
Closed 23 years ago
Freeze nsIClassInfo
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
mozilla1.0
People
(Reporter: dougt, Assigned: dougt)
References
Details
Attachments
(1 file)
942 bytes,
patch
|
Details | Diff | Splinter Review |
plugin requirement.
Assignee | ||
Comment 1•23 years ago
|
||
If 93222 is unblocked, Index: nsIClassInfo.idl =================================================================== RCS file: /cvsroot/mozilla/xpcom/components/nsIClassInfo.idl,v retrieving revision 1.6 diff -u -r1.6 nsIClassInfo.idl --- nsIClassInfo.idl 2001/08/28 21:46:08 1.6 +++ nsIClassInfo.idl 2001/09/25 00:21:37 @@ -36,6 +36,11 @@ #include "nsISupports.idl" #include "nsIProgrammingLanguage.idl" +/** + * Provides information about a specific implementation class + * @status FROZEN + */ + [scriptable, uuid(986c11d0-f340-11d4-9075-0010a4e73d9a)] interface nsIClassInfo : nsISupports {
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → mozilla1.0
Assignee | ||
Comment 2•23 years ago
|
||
So, what is the plan? Here is what I am thinking: Freeze nsIClassInfo without classIDNoAlloc. Create nsIClassInfo2 which derives from nsIClassInfo Add a function to support 93222 to nsIClassInfo2 (impl. as NS_ERROR_NOT_IMPLEMENTED util someone (david) can look at fixing it). Fixup the implementations to know about nsIClassInfo2. what are we missing??
Comment 3•23 years ago
|
||
I spoke with beard about this mess (as discussed at length in bug 93222). He supported the idea of *not* retroactively freezing nsIClassInfo. His thought was that the version that matters for plugin developers is not what's in the tree now (or in the recent past). Instead, the on that matters is the version in the upcoming plugin SDK. So, let's decide if we want to add new stuff and run this through the freeze process. As long as we only add new stuff on the end of the existing interface, then plugins called from 'old' browsers will work fine. As shaver has pointed out, there are no plugins implementing any old version of this interface. So, that aspect of backward compatibility is a non-issue. So, let's figure out now how (or if) this interface should change from the version in the trunk and then just freeze it. Maybe we can avoid nsIClassInfo2 forever.
Comment 4•23 years ago
|
||
I agree with what you are saying, in principle, jband, but we have a practical concern here as well, developers targeting Netscape 6.1. If a developer wants to create a scriptable plugin that runs in both 6.1 (0.9.2) and 6.x where x > 1, then that developer would have to build his plugin against the latest version of nsIClassInfo. The checked in version of our sample scriptable plugin is obviously written this way, but there may be a narrow window where we told developers to use our sample code, before we added the GetClassIDNoAlloc method. Arun, do you know when we first pointed developers to our scriptable 4.X plugin solution, and if there are any developers currently building scriptable plugins relative to our 6.1 (0.9.2) source release? If there are no developers doing this, then I guess it is safe to freeze nsIClassInfo with GetClassIDNoAlloc included.
What about developers targetting 0.9.3 (a variant of which OEone is currently using)? What about developers targetting 0.9.2, which ships with Red Hat 7.2? Or Netscape 6.0? If. You. Use. A. Version. Prior. To. Freezing. Or. Mozilla. Publishing. A. Plugin. SDK. You. May. Have. To. Recompile. Why is recompiling such a burden? Are there any at-risk plugins in the field now? (If you know of people developing plugins right now for near-term deployment, _please_ do them a favour and warn them about this issue.) They can implement the new things-at-the-end nsIClassInfo (via a macro, no doubt), and as long as they don't call GetClassIDNoAlloc or HasClassIDs on pre-0.9.6 nsIClassInfo implementations -- which I can't see them doing -- then they're fine.
Comment 6•23 years ago
|
||
We are publishing a plugin SDK *real soon now*. It's a burden if you have to recompile for every release of a commercial product. And it's a nightmare for users to have to go find the CORRECT plugin for each new release. If we bundle all of the important plugins, then it's easier to manage, but I doubt that's the ultimate solution to this problem.
Comment 7•23 years ago
|
||
One issue that concerns me about adding new methods, is how will future browsers know when it is safe to call the newler methods? Should we have some sort of informal versioning information, such as "feature" flags which would indicate something like "this classinfo supports getting a CID without allocating memory". It's ad hoc, but it might be necessary.
> We are publishing a plugin SDK *real soon now*. Great! Then let's have These Plugin Vendors recompile _once_ against this plugin SDK -- which will only contain frozen interfaces, right? (I'm sorry that people have to keep recompiling their plugins for every Netscape commercial version. The same thing happens when Linux distributions ship development-stream kernels; people have to rebuild modules a bunch of times. And you know what? Life Goes On.) > One issue that concerns me about adding new methods, is how will future > browsers know when it is safe to call the newler methods? They don't. That's kinda the whole point behind this discussion. (And it's why you don't use non-frozen APIs and expect long-term binary compatibility, in case anyone is missing my major thesis here.)
Assignee | ||
Comment 9•23 years ago
|
||
Mike, nsIClassInfo was shown to the public as a "frozen interface". Examples were posted to the mozilla.org webpage.
"Examples were posted to the mozilla.org webpage" doesn't equal "freezing", to me. mozIRegistry and the old string stuff and NSRegisterSelf and pre-1.0 XUL stuff and old RDF APIs are up there, too, and I don't think we froze them. We _still_ have huge docs up there pointing at the XPCOM plugin API, which really breaks my heart. nsIClassInfo was presented to website readers _exactly_ as nsISecurityCheckedComponent had been 4 months prior. On the same page, in the same place. I Am Not Buying It. An appearance on mozilla.org's website is no substitute for @FROZEN, and I think we've said _that_ on our web site, too. Do you really want it to be otherwise? Do you really want to freeze nsISecurityCheckedComponent and NSGetFactory and put back all the old RDF interfaces, just for a start?
Assignee | ||
Comment 11•23 years ago
|
||
No, I am mearly pointing out that we may screw (again) some plugin developers.
We screwed them in August with the nsIClassInfo change, and we're screwing them _today_ with the presence of the XPCOM plugin API docs. At some point, someone will bother to tell plugin developers (again?) to avoid un@FROZEN APIs, or they'll learn it themselves. ("Hey, it hurts _every_time_ I do that!")
Comment 13•23 years ago
|
||
where are the XPCOM API docs? I'm going to cvs remove them.
http://www.mozilla.org/docs/plugin.html, at least. I love you, man.
Comment 15•23 years ago
|
||
Documentation references to the XPCOM plugin are gone. Doug, can you provide a patch that includes @status FROZEN for this? Also, please remove the "XXX ..." comment under the flags. Further nsIClassInfo development needs to happen w/ a new interface. Please see the netscape.public.mozilla.plugins posting today regarding the API review that came to consensus on the freezing of this interface. Folks can mull notes at http://www.mozilla.org/projects/embedding/apiReviewNotes.html#Plugins (once the server updates w/ the new doc).
Comment 16•23 years ago
|
||
Note that we agreed to *consider* additional informational flag constants on a case by case basis if we feel the need in the future. But the attributes and methods are frozen. Adding more of them requires a new interface.
Comment 17•23 years ago
|
||
Removing bug 93222 as a blocker to this bug. Objection withdrawn.
No longer depends on: 93222
Assignee | ||
Comment 18•23 years ago
|
||
Assignee | ||
Comment 19•23 years ago
|
||
should we also remove these comments: ///////////////////////////////////////////////////////////////////////// // The above methods and attributes existed in Netscape6.1 and mozilla0.9.2. // New methods and attributes must be added to the *end* of the interface // RESIST THE INCLINATION TO PLACE THEM ABOVE WHERE THEY *SEEM* TO BELONG. /////////////////////////////////////////////////////////////////////////
Yes, let's remove it. Nobody should be adding new methods or attributes.
Comment 21•23 years ago
|
||
I agree.
Assignee | ||
Comment 22•23 years ago
|
||
can someone slap some r/sr's on this? (can't attach a patch right now for whatever reason) Index: nsIClassInfo.idl =================================================================== RCS file: /cvsroot/mozilla/xpcom/components/nsIClassInfo.idl,v retrieving revision 1.6 diff -u -r1.6 nsIClassInfo.idl --- nsIClassInfo.idl 2001/08/28 21:46:08 1.6 +++ nsIClassInfo.idl 2001/10/12 14:18:06 @@ -36,6 +36,11 @@ #include "nsISupports.idl" #include "nsIProgrammingLanguage.idl" +/** + * Provides information about a specific implementation class + * @status FROZEN + */ + [scriptable, uuid(986c11d0-f340-11d4-9075-0010a4e73d9a)] interface nsIClassInfo : nsISupports { @@ -97,8 +102,6 @@ const PRUint32 PLUGIN_OBJECT = 1 << 4; const PRUint32 EAGER_CLASSINFO = 1 << 5; - // XXX what else might we want to add? - // The high order bit is RESERVED for consumers of these flags. // No implementor of this interface should ever return flags // with this bit set. @@ -106,12 +109,6 @@ readonly attribute PRUint32 flags; - - ///////////////////////////////////////////////////////////////////////// - // The above methods and attributes existed in Netscape6.1 and mozilla0.9.2. - // New methods and attributes must be added to the *end* of the interface - // RESIST THE INCLINATION TO PLACE THEM ABOVE WHERE THEY *SEEM* TO BELONG. - ///////////////////////////////////////////////////////////////////////// /** * Also a class ID through which an instance of this class can be created
Comment 23•23 years ago
|
||
r=dbradley
sr=shaver. (Man, am I going to be glad to close this bug.)
Assignee | ||
Comment 25•23 years ago
|
||
Checking in nsIClassInfo.idl; /cvsroot/mozilla/xpcom/components/nsIClassInfo.idl,v <-- nsIClassInfo.idl new revision: 1.7; previous revision: 1.6 done thanks all.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•