Doug Turner wrote:
> I am pushing to freeze the core parts of XPCOM. The reason is simple,
> changes are busting users of xpcom clients. There needs to be a
> definitive list of the frozen API which embedders and xpcom developers
> can reference.
I think it's premature to be freezing large pieces of XPCOM. We _know_
that we're going to be making some substantial changes to things like
the nsIComponentManager/nsIServiceManager relationship, and we need to
do some hard thinking about what our interfaces need to look like so as
to support things like multiple XPCOM registries.
> Here is the first cut of the XPCOM interfaces that need to be frozen.
...or not. I maintain that some of those things (nsAgg.h? nsCOMPtr.h?
ns_Debug_h!) should not be "frozen" even for Mozilla 1.0. We need to
determine what sorts of extensions and interactions XPCOM needs to
support for 1.0, and fix-n-freeze the APIs required to meet those goals,
rather than standardizing on something just because it's in the tree.
(nsCOMPtr.h needs a conditioning #ifdef that makes everything inline, so
people can use it without linking to libxpcom, I think, rather than
freezing the hidden, quirky implementation details.)
> nsIGenericFactory.h
This is a great example of where we need to take care.
Code within the Mozilla core, which must evolve in binary-lockstep at
least until 1.0, should use an NS_IMPL_GETMODULE definition that shares
a common implementation, to reduce code size. Code in plugins and
extension components should get (or have available; plugins that want to
ride the binary-API-change train are welcome aboard) a macro set that
expands to completely inline code, so that we reduce the number of API
points with signatures and semantics we have to support forever.
> nsIShutdownListener (can we get rid of??)
I hope so -- sounds like a nail looking for the nsIObserver hammer.
> nsIEventQueue
> nsIEventQueueService
What's the need to freeze these? Who uses them? Should we expose an
embedding-style basic interface to simply spin up the event queue
"correctly", so that we don't have to get those semantics perfect on
this try? (The embedding-team strategy of writing interfaces that
express minimal sets of operations and implementing those in terms of
our "real" interfaces works very well for this sort of "control
interface", and lets us provide useful, stable functionality to
embedders and extenders without handcuffing ourselves. We need more of
that in Mozilla.)
> nsIFileSpec (deprecated but some legacy code uses it)
Don't freeze it. If you write code in the year 2001 that uses
nsIFileSpec, you should feel lucky that it's your code that breaks, and
not your knees.
> *nsIEnumerator
No. nsIEnumerator must die. nsISimpleEnumerator is suitable for
freezing and publishing, but only after we rename it to nsIEnumerator.
Mike
