Rick Potts wrote:
> Again... the current static nsServiceManager class has been exposed to
> external plugin developers for over a year. We do not propose to
> promote this depricated interface. However, if this API is frozen (and
> being used) we cannot simply remove it.
This interface was "just" broken, and will continue to be broken by
name-mangling issues between C++ compilers, etc. That's one of the
reasons people use (XP)COM: C++ binary interfaces are too fragile on
their own.
All sorts of stuff in our codebase is "exposed" to plugin developers, by
virtue of not having static linkage. We can't be handcuffed by the fact
that people are choosing to write -- or might be choosing to write: some
organizations aren't very public about their use of Mozilla -- to
non-frozen APIs; we'd have to bring back the old network utility
libraries and freeze libmsgutil and so forth. Nobody wants that.
For Mozilla 1.0, we'll have XPCOM and other things frozen. Right now,
we don't. Plugin developers should use the 4.x NPAPI, or wait until the
interfaces are frozen, or be willing to ride the tip. We can't
substitute "some company shipped a plugin against a pre-release API" for
a reasoned and cogent API review process.
Mike
