Steven Katz wrote:
> Hello,
>
> Speaking as a plugin developer (the Java Plugin in specific) I can tell you that
> we are feeling a great deal of pain over this.
Sorry about your troubles. Plugin venders will continue to feel pain until the API
which they have written against is frozen. If you could help me by identifying what
interfaces and classes you are using, and send me that list. In this
way, when we are done with the first pass through xpcom most, if not
all, of the API you use will have been completely frozen.
> I agree with Mike that the current state of affairs is not so good and would
> love to see it reworked. BUT, since Netscape has shipped a browser and since we
> where told that we needed to adopt the "New" plugin interface to support that
> browser our expectation is that the plugin that supports 6.1 will continue to
> work with subsequent releases (binary compatability). I understand that mozilla
> doesn't equal Netscape, so mabey it's up to the Netscape enginers to insure that
> this is what happens, I don't know.
>
> As of now, the plugin we have in development does support Netscape6.1 (using
> nsIModule), but it fails to work with the tip (regxpcom fails) so it is possible
> that there won't be a Java for Mozilla until the next release of the plugin (and
> we now how long that can be).
I understand. We are trying to maintain backwards compatibility. I am
not sure that bug that you have cited is related to any of our API
freezing.
> Above all else, these interfaces, and how to use them, needs to be document. If
> you don't want people to use the "New" (NSGetFactory) interface then remove that
> documetation from the website. If you want people to use nsIModule, then
> document it and make sure that the examples you give are up to date.
Aside from the ever-changing apis, this is by far the next biggest
problem. I am checking with my team to see if I can get a person
dedicated to this. If anyone is interested in working on this, please
contact me.
doug turner
