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.
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).
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.
stevek
In article <[EMAIL PROTECTED]>, Mike Shaver says...
>
>Doug Turner wrote:
>
>> so, nsServiceManager adds the growing list of "things that people are
>> using that we shouldn't break and we don't want to support".
>
>
>I think it was broken recently, according to some reports of the beta
>(!) Java plugin not working.
>
>I guess we need to leave it in, because it's widely used by Mozilla-core
>code, so maybe source-compatible is enough. (Or maybe too much; I think
>there are some things in the service manager that predate our
>comptrization of the world.)
>
>> Actually, as of a few days ago, you could try to QI the
>> nsIComponentManager for the nsIServiceManager. Unless somone has
>> changed something in their tree, this should work..
>
>Excellent news.
>
>Mike
>
