I think that we are mixing up things here. The nsServiceManager can be
part of a static library which gets punted to plugin venders. Plugin
venders will have to relink to this new library, but their code will
effectively remain the same. Stuff in this static lib, can be in flux
as long as what it depends on does not change.
Does this make sense?
I mean, we freeze nsIServiceManager. For those that need a helper class
, they can link to a seperate lib that give this to them. They don't
have to directly link to xpcom.
Mike Shaver wrote:
> 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
>
>
