"Michael Ang" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Peter Sorotokin wrote:
> >
> > Some people suggested that in Mozilla/XPCOM
> > world it is OK to change interface if it is not frozen, and there is no
> > need to change its IID. That makes it impossible to do anything at all
> > with non-frozen interfaces, because if it is ever changed, my code will
> > simply crash (and users will blame me). On the other hand, if interface
> > is changed, but its IID is also changed, I at least can do something
sane.
> > [...]
> > Would it be feasible for Mozila to change IID of *any* interface every
> > time its vtable layout is changed (this would not seem to require
anything
> > but IID string change in the same IDL file)?
>
> Are you also hoping that the old interfaces will still be available, or
At the very least, I want to detect that interface is not available and tell
user
that my plugin will not work with this version of the browser. If IIDs are
not
frozen, the only other choice I have is to detect browser version upfront
and plainly refuse to do anything if it is not what I expect (but as I said,
we
might simply choose not to support scripting in Mozilla and stick to the
old NN4.x plug-in architecture). I also can disable parts of the plug-in
functionality (like scripting) in some cases; but at least I can tell the
user
that's going on.
> do you just want to be able to detect the change (through
> NS_ERROR_NO_INTERFACE)? When you say you can "do something sane" if the
> IID changes, I'm assuming all you can do is bail out gracefully. It
I can prevent crashing, at least; I can also avoid refusing to work with
any non-supported browser version.
> sounds to me that the real win will be to put effort into reviewing and
> freezing more interfaces.
Yes, but who is supposed to do that? Do you suggest people like me (not
very knowlegable in Mozilla internals) should take part in that?
Peter
>
> - Mike.
