Doug Turner wrote:
> 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?
As a general strategy, I think it makes a lot of sense -- things like
nsCOMPtr and maybe the generic-module bits really want that sort of
treatment.
> 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.
Who "needs" a helper class? People are expected to access the component
manager through the interface pointer we give them, and I think the only
reason that people are using nsServiceManager:: right now is that we
don't pass nsIServiceManager into nsIModule::getClassObject. Once we
fix that -- which we get for free with the compmgr/servmgr merger,
right? -- there will be no need for such use, just as there's no need
for nsComponentManager:: to be frozen and supported.
Mike
