I am not sure exactly what the point is of having two libraries. I mean, I would think that we should strive to get some concrete set of public interfaces and include together and publish these to component and plugin developers. What does it matter if the there is obsolete cruft in the library?
Mike Shaver wrote: > Let's ship libxpcom10.so with Mozilla 1.0. And people who want to use > plugins that need the nsServiceManager:: and other APIs can install > libxpcom.so[*] for compatibility. This way we get to build clean APIs, > and not break anyone that the distributor doesn't want to break. We'd > need to make libxpcom.so speak "XPCOM 1.0" to libxpcom10.so for some > things, so that they could share singleton services and whatnot, but it > really puts the binary compatibility bar as high as we're willing to > make it. > > I've half-thought of the mechanics of mapping contract IDs and > interfaces around so that everyone sees the things they want to see on > both sides of the API divide, but I'm too tired to really get into the > details now. (And it's too large to fit in the margin.) But I think > the idea at least bears discussing. > > [*] On systems with rich enough DSO support, we could probably call the > real library libxpcom.so and the compatibility library libxpcom_obs.so, > with appropriate sonames for each. > > Mike >
