Mike Shaver wrote:
> 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.
I never said we are going to freeze large pieces. I said 'core parts of
xpcom'. We need to be able to have a set of frozen interfaces that will
allow initialiation, basic component handling, and shutdown. Most of
these interfaces are already 'defacto' frozen. I want to add some
assurance to clients that there is a set of core xpcom apis which are
frozen.
We have many customers of XPCOM which have no idea which API's to use.
They break between builds. This is unacceptable. Furthermore, we can
not freeze our embedding APIs until there is enough core xpcom.
What is the problem with the current
nsIComponentManager/nsIServiceManager relationship? If this is related
to merging the two, see 96457.
>> 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.)
It has been suggested that we could also provide a static libary of
these functions, ect. If needed xpcom clients (eg plugins) could
directly link to this library without having to pull in all of xpcom.
Does this sound like a good plan to you?
>> 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.
This can be part of a helper static library/
>> nsIShutdownListener (can we get rid of??)
>
> I hope so -- sounds like a nail looking for the nsIObserver hammer.
It is barely used anymore. dp riped most of it out.
>> 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.)
The only worry is that there are many places when writing an application
built with mozilla that you need to push an event queue. How can this
be handled? Should we create an embedding interface for this? Jud?
>> 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.
I would love to. Need to double check why this showed up as a dependancy.
>> *nsIEnumerator
>
> No. nsIEnumerator must die. nsISimpleEnumerator is suitable for
> freezing and publishing, but only after we rename it to nsIEnumerator.
Sounds good. Thanks for your comments. I will update my list, and
start filling bugs (if none exist).
