Closed Bug 93222 Opened 23 years ago Closed 7 years ago

nsIClassInfo object needs to be able to represent multiple CID's

Categories

(Core :: XPConnect, enhancement, P3)

Product:
Core
Component:
XPConnect
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: dbradley, Assigned: dbradley)

Details

Currently classinfo objects only support returning a single CID. Adding a
"hasInstance" method would allow a caller to ask the classinfo object if it
supported a given CID. This also makes the InstanceOf support provided by nsJSCI
more straightforward.
Note bug 99158. nsIClassInfo is being frozen.
marking as a blocker until we know if we should hold freezing nsIClassInfo for
this bug.
Blocks: 99158
Other than streamlining nsJSCI are there other uses? I seemed to recall some
reference to versioning of implementation.

Is the intent to add the method and then just add simple logic to test against
the classID attribute in the existing implmeentations: nsDOMClassInfo,
nsGenericFactory, as well as the nsClassInfoMixin in the plugin samples for 4x?
And then future implementations could have more complex logic? Or were you
thinking of something more extensive in this change?
Status: NEW → ASSIGNED
Priority: -- → P3
Yes, I was suggesting this both for streamlining and because I imagine that (in
the future) some components might be vending objects of the same class when
asked for cid Foo and cid Bar. This allows for extending class capabilities
while providing backward compatibility.

             servers               clients
             -------               -------
version A:   implements Foo        asks for Foo
version B:   implements Foo&Bar    asks for Bar - can ask for Foo in a pinch

The version A client will work with either server. In a system where the version
B server has been installed that server will shadow (and hide) the version A
server. The version B client is protected from the mistake of getting an object
that only does Foo (but not Bar) in a system that has only the version A server.
That client can be coded to fall back on using onthe the Foo server and its
limited capabilities if necessary.

I'm afraid that as we paint ourselves into a corner we are going to be needing
some of these tricks.

And, yes, I imagined that the default implementations we have would do the
simple minded one-to-one comparison. At some future point we'd implement
classinfos to handle these more complicated cases. This bug is about laying
groundwork.

We *may* want both a "hasInstance" and a getter for the array of cids (just like
our getter for the array of iids).

In practical terms it *may* be too late to make this change without extending
nsIClassInfo (with an additional iid). We've suggested the use of nsIClassInfo
for plugins and many of those plugins are likely to get built against pre-0.0.5
versions of nsIClassinfo.idl - so won't have new methods. We could consider
using up one of the flags in that class to indicate "has method: hasInstance".
But, that is quite a one-off solution. Rev'ing the iid is *supposed* to be the
way this is done.

Comments anyone else?
Who's recommending use of unfrozen APIs to plugin developers again?  Will we
never learn?  We can't go spinning off new interfaces and IIDs for every
milestone because someone decided that a) they wanted to use the tip's unfrozen
interfaces, and b) they can't be bothered to keep up with future versions of
that API, until the point of freezing.

> Rev'ing the iid is *supposed* to be the way this is done.

That's true, but only in conjunction with "not evangelizing unfrozen
APIs-of-the-week is *supposed* to be what's done".

I don't even buy the comment
110 /////////////////////////////////////////////////////////////////////////
111 // The above methods and attributes existed in Netscape6.1 and mozilla0.9.2. 
112 // New methods and attributes must be added to the *end* of the interface
113 // RESIST THE INCLINATION TO PLACE THEM ABOVE WHERE THEY *SEEM* TO BELONG.
114 /////////////////////////////////////////////////////////////////////////

Mozilla 0.9.2 has a zero at the beginning for a reason.  We shipped a lot of
APIs in Mozilla 0.9.2, most of them aren't frozen, that's life for people who
want to develop against the pre-releases.  That's why Mozilla doesn't use
pre-releases of pango and gtk2 and such, or why we have to keep upgrading and
adding compatibility glue when we do -- remember libIDL?  (And it's not like
putting new methods at the end of an interface is safe, especially given that
the interface is designed to be implemented by, and not just called by,
extenders and embedders.)

Let's put nsIClassInfo through the API-review mill, so we can freeze it and
_then_ tell people to use it.
> Who's recommending use of unfrozen APIs to plugin developers again? ...

Me.

Tell me your better plan for scriptable plugins. We're backing up to pushing 4.x 
style plugins but we lacked a good story for scriptability. Plugins that would 
work with NS6.1 was considered a requirement. There was already a published 
recomendation to use nsISecurityCheckedComponent to get the caps system off the 
plugin's back. I argued that selling nsIClassInfo was a better answer. I see 
your address on the emails of that thread, so I'm not going to reiterate the 
whole discussion.

I too would like to make no promises to anyone until we are happy with every api 
we are going to claim to support. But we're trying to live in the real world 
here.
So because we're living in the real world, we can add classIDNoAlloc, but we
can't add hasInstance?  Either we need binary compatibility -- which we didn't
when we (correctly and usefully, IMO) added classIDNoAlloc for fastload and
others -- or we don't and we can add hasInstance cleanly now.

Has anyone actually shipped a plugin that
 - works with NS6.1/Mozilla0.9.2, and
 - wasn't broken by the classIDNoAlloc change, and
 - will be broken by the hasInstance change?

I can't imagine how.  (Of course, those plugins will crash "6.2", or Mozilla
0.9.5, if we try to call classIDNoAlloc on them -- do we care about that?)
Who are we really breaking?  Can we hear from them in this bug, so we can figure
out what it really costs Mozilla to make a change, and we can weigh that
intelligently against the ick and pain of nsIClassInfoEx or whatever?  I think
that'd be better than you and I slinging ad-hominem bug comments around for
days, entertaining though the prospect seems at 2:15am.

(As far as scriptable plugins, I always liked the JNI<->JRI bridge. =) )

Should we do what jband suggested in a email - create a nsIClassInfo2 with
classIDNoAlloc and a "hasInstance" method?  I am fine with this suggestion if
there are shipped clients actual using nsIClassInfo interface.  (who are they?)


I'm happy with the nsIClassInfo2 solution. This is the right way to do this,
given our decision to promote nsIClassInfo for scriptable plugins. Mike, you may
be correct that nobody has shipped a scriptable plugin based on this mechanism,
but we don't want to go changing these things capriciously if we can avoid it.
BTW, would nsIClassInfo2 subclass nsIClassInfo or just be a completely new
interface?
In this case, subclass, I would think.  

So, the plan is to create a new interface nsIClassInfo2 which derives from
nsIClassInfo.  We will move classIDNoAlloc and a "hasInstance" method into the
nsIClassInfo2.  Sounds fine by me.

David, could you send me what the idl should look like for the "hasInstance"
method?  We can implement it later.  I want to get the IDL in place as soon as
possible.

If we go that route then we need to fix nsGenericFactory and be sure that all 
the QI implementations of classes that implement nsIClassInfo2 have cases for 
*both* nsIClassInfo and nsIClassInfo2 iids.

why do we have nsGenericFactory for class info?  
nevermind.  I understand why.
There's nothing capricious about it, I don't think, but then I seem to live in
my own little world where simply telling someone to use an API doesn't freeze
it.  Which is to say: I'm still not buying it.

Multiplying our unfrozen interfaces to support people who haven't shipped
anything yet seems capricious to me, especially since nobody can even cough up
_one_ group that would be seriously harmed by this change.  Again, I point at
the COM and DirectX examples: if you use the interfaces in preview/beta releases
-- even if you ship a product on it, silly you -- you buy the
possibly-but-not-likely-zero pain required to follow the interface through its
changes to actual release.  Nobody versions unfrozen interfaces, that I can
find.  Why do you think that is?

Why are we borrowing this trouble in the name of phantom consumers? 
_Especially_ when we've already shipped milestones with the cardinal sin of
classIDNoAlloc, and the world failed to crumble around us.

I'm sorry that people felt they could freeze and promote nsIClassInfo without
putting it through the API review process, and I'm a little surprised: the issue
of which interfaces to freeze and expose was central to the decision, so why
didn't advocates of this approach to scriptable plugins follow through?  It's
not like we aren't waist-deep in precedent around the pain of advocating
unfinished APIs to plugin developers, or anything.

(Given the definition of "capricious" as "subject to sudden change", I think our
non-frozen interfaces qualify.  Who would really think otherwise?  Who would
want to lead them to believe so?)

nsIClassInfo is a small piece of our XPCOM API puzzle, and one that might
someday be hidden from implementors by macros, but I think that the precedent
people are trying to establish here (freezing through shadowy claims of
premature downstream adoption, rather than the long-established API review
process) really stinks.  But maybe I'm the only one who cares.  Bah.

No, shaver -- I agree with you.  I do not want to see an nsIClassInfo2.  Perhaps
different from you, OTOH, I don't mind jband's hack to move members added after
a major Mozilla derivative shipped to the end -- it seemed to help.

/be
I don't mind that either, I was just citing it as another recent example of
breaking binary compatibility for a good reason.  All hail putting them at the end.
Lets move the conversation about "Interface renaming - Backwards Compatiblity"
to the xpcom newsgroup.  More people should be involved in this discussion. 
Plus, this conversation has nothing to do with representing multiple CID with a
nsIClassInfo object :-)
I'd like to disabuse folks of a few flawed assumptions. I talk to several consumers:

>Why are we borrowing this trouble in the name of phantom consumers? 

These consumers are no longer phantom, and ceased being phantom following a
thread that you were CC'd on well over a month ago, shaver -- this was the
thread that finished preferring nsIClassInfo to nsISecurityCheckedComponent. 
'nsIClassInfo' as suggested in mozilla.org/docs/scriptable-plugins.html is being
adopted by vendors seeking scriptability.

I'm loath to mention these vendors by name here, since they've commited to
working on this to suit a deadline, but important "commercial" browsers stemming
from Mozilla (albeit 0.x) depend on partners making plugins that work for these
browsers, and NOT in a substandard manner.  This means scriptability.

JNI<->JRI bridge (a.k.a. LiveConnect) is a no-go -- ask beard, upon who this
work would fall.
No longer blocks: 99158
It was decided that this is not going into nsIClassInfo before that interface is 
frozen. If anyone need this functionality then a new interface will be required.  
If that happens then anyone wanting to attempt to call this method will have to 
QI the target object to that new interface in order to do the call.

We can mark this bug 'future' or whatever. AFAIC, we just don't need it at this 
point.
Ok, marking future
Target Milestone: --- → Future
QA Contact: pschwartau → xpconnect
Class info is probably not going to get new features at this point.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.