Closed Bug 99158 Opened 23 years ago Closed 23 years ago

Freeze nsIClassInfo

Categories

(Core :: XPCOM, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.0

People

(Reporter: dougt, Assigned: dougt)

References

Details

Attachments

(1 file)

plugin requirement.
Blocks: 98278
Depends on: 93222
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
 {

Target Milestone: --- → mozilla1.0
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??
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. 
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.
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.
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.)
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?
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!")
where are the XPCOM API docs? I'm going to cvs remove them.
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).
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.
Removing bug 93222 as a blocker to this bug. Objection withdrawn. 
No longer depends on: 93222
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.
I agree.
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
r=dbradley
sr=shaver.  (Man, am I going to be glad to close this bug.)
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.